Tagged: mozilla

I have joined tableflip club

If you’ve never heard of tableflip, read this.

After nearly 4 years of employment, I have given notice at Mozilla. My last day will be 27 August.

I’m not going quietly.

Mozilla has serious, systemic cultural and organizational issues. Addressing these is imperative to Mozilla’s advancing its stated mission to “promote openness, innovation & opportunity on the Web.”

In the coming weeks, I’ll be writing more about Mozilla. In the meantime, you can read these collected tweets about why I’m leaving: part 1 and part 2.

The Recompiler: Now with more podcast!

The Recompiler logoIf you’ve been watching my tweetstream recently, you know that The Recompiler (@recompilermag), a magazine about technology, is in the final days hours of it’s inaugural subscription drive.

Yesterday, Audrey announced that we’re going create a podcast version of The Recompiler!

Some of you may have listened to In Beta, which I co-hosted last year. Doing that podcast was great fun and I’m so looking forward to hosting this supplement to The Recompiler. The podcast will enhance the written version of the magazine with tech news, criticism & commentary plus interviews with our authors.

If you’re craving awesome, insightful conversation on technical topics from fresh, less-heard-from voices, then The Recompiler podcast is for you!

Get involved and support The Recompiler today by purchasing a subscription and look for the first written issue and episode this summer!

Fun with git submodules

Git submodules are amazingly useful. Because they provide a way for you to connect external, separate git repositories they can be used to organize your vim scripts, your dotfiles, or even a whole mediawiki deployment.

As incredibly useful as git submodules are, they can also be a bit confusing to use. This goal of this article is to walk you through the most common git submodule tasks: adding, removing and updating. We’ll also review briefly how to make changes to code you have checked out as a submodule.

I’ve created some practice repositories. Fork submodule-practice if you’d like to follow along. We’ll used these test repositories as submodules:

I’ve used version 2.3.0 of the git client for these examples. If you’re seeing something different, check your version with git --version.

Initializing a repository with submodules

First, let’s clone our practice repository:

[skade ;) ~/Work] 
christie$ git clone git@github.com:christi3k/submodule-practice.git
Cloning into 'submodule-practice'...
remote: Counting objects: 63, done.
remote: Compressing objects: 100% (16/16), done.
remote: Total 63 (delta 9), reused 0 (delta 0), pack-reused 47
Receiving objects: 100% (63/63), 6.99 KiB | 0 bytes/s, done.
Resolving deltas: 100% (25/25), done.
Checking connectivity... done.

And then cd into the working directory:

christie$ cd submodule-practice/

Currently, this project has two submodules: furry-octo-nemesis and psychic-avenger.

When we run ls we see directories for these submodules:

[skade ;) ~/Work/submodule-practice (master)] 
christie$ ll
▕ drwxrwxr-x▏christie:christie│4  min │   4K│furry-octo-nemesis
▕ drwxrwxr-x▏christie:christie│4  min │   4K│psychic-avenger
▕ -rw-rw-r--▏christie:christie│4  min │  29B│README.md
▕ -rw-rw-r--▏christie:christie│4  min │ 110B│README.mediawiki

But if we run ls for either submodule directory we see they are empty. This is because the submodules have not yet been initialized or updated.

[skade ;) ~/Work/submodule-practice (master)] 
christie$ git submodule init
Submodule 'furry-octo-nemesis' (git@github.com:christi3k/furry-octo-nemesis.git) registered for path 'furry-octo-nemesis'
Submodule 'psychic-avenger' (git@github.com:christi3k/psychic-avenger.git) registered for path 'psychic-avenger'

git submodule init copies the submodule names, urls and other details from .gitmodules to .git/config, which is where git looks for config details it should apply to your working copy.

git submodule init does not update or otherwise alter information in .git/config. If you have changed .gitmodules for any submodule already initialized, you’ll need to deinit and init the submodule again for changes to be reflected in .git/config.

You can initialize specific submodules by specifying their name:

git submodule init psychich-avenger

At this point you could customized git submodule urls for use in your local checkout by editing them in .git/config before proceeding to git submodule update.

Now let’s actually checkout the submodules with submodule update:

skade ;) ~/Work/submodule-practice (master)] 
christie$ git submodule update --recursive
Cloning into 'furry-octo-nemesis'...
remote: Counting objects: 6, done.
remote: Total 6 (delta 0), reused 0 (delta 0), pack-reused 6
Receiving objects: 100% (6/6), done.
Checking connectivity... done.
Submodule path 'furry-octo-nemesis': checked out '1c4b231fa0bcfd5ce8b8a2773c6616689032d353'
Cloning into 'psychic-avenger'...
remote: Counting objects: 25, done.
remote: Compressing objects: 100% (9/9), done.
remote: Total 25 (delta 1), reused 0 (delta 0), pack-reused 15
Receiving objects: 100% (25/25), done.
Resolving deltas: 100% (3/3), done.
Checking connectivity... done.
Submodule path 'psychic-avenger': checked out '169c5c56154f58fd745352c4f30aa0d4a1d7a88e'

Note: The --recursive flag tells git to recurse into submodule directories and run update on any submodules those submodules include. It’s not needed for this example, but I’ve included it here anyway since it’s common for projects to have nested submodules.

Now when we run ls on either directory, we see they now contain our submodule’s files:

[skade ;) ~/Work/submodule-practice (master)] 
christie$ ls furry-octo-nemesis/
▕ -rw-rw-r--▏42 sec │  52B│README.md

[skade ;) ~/Work/submodule-practice (master)] 
christie$ ls psychic-avenger/
▕ -rw-rw-r--▏46 sec │ 133B│README.md
▕ -rw-rw-r--▏46 sec │   0B│other.txt

Note: It’s possible to run init and update in one command with git submodule update --init --recursive

Adding a git submodule

We’ll start in the working directory of submodule-practice.

To add a submodule, use:

git submodule add <git-url>

Let’s try adding sample project scaling-octo-wallhack as a submodule.

[2495][skade ;) ~/Work/submodule-practice (master)] 
christie$ git submodule add git@github.com:christi3k/scaling-octo-wallhack.git
Cloning into 'scaling-octo-wallhack'...
remote: Counting objects: 19, done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 19 (delta 1), reused 0 (delta 0), pack-reused 9
Receiving objects: 100% (19/19), done.
Resolving deltas: 100% (3/3), done.
Checking connectivity... done.

Note: If you want the submodule to be cloned into a directory other than ‘scaling-octo-wallhack’ then you need to specify a directory to clone into as you would when cloning any other project. For example, this command will clone psychic-avenger to the subdirectory submodules:

christie$ git submodule add git@github.com:christi3k/scaling-octo-wallhack.git submodules/scaling-octo-wallhack

Let’s see what git status tells us:

[skade ;) ~/Work/submodule-practice (master +)] 
christie$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	modified:   .gitmodules
	new file:   scaling-octo-wallhack

And running ls we see that there are files in scaling-octo-wallhack directory:

[skade ;) ~/Work/submodule-practice (master +)] 
christie$ ll scaling-octo-wallhack/
▕ -rw-rw-r--▏christie:christie│<  min │ 180B│README.md
▕ -rw-rw-r--▏christie:christie│<  min │   0B│cutting-edge-changes.txt
▕ -rw-rw-r--▏christie:christie│<  min │   0B│file1.txt
▕ -rw-rw-r--▏christie:christie│<  min │   0B│file2.txt

Specifying a branch

When you add a git submodule, git makes some assumptions for you. It sets up a remote repository to the submodule called ‘origin’ and it checksout the ‘master’ branch for you. In many cases you may no want to use the master branch. Luckily, this is easy to change.

There are two methods to specific which branch of the submodule should be checked out by your project.

Method 1: Specify a branch in .gitmodules

Here’s what the modified section of .gitmodules looks like for scaling-octo-wallhack:

[submodule "scaling-octo-wallhack"]
  path = scaling-octo-wallhack
  url = git@github.com:christi3k/scaling-octo-wallhack.git
  branch  = REL_1

Be sure to save .gitmodules and then run git submodule update --remote:

[skade ;( ~/Work/submodule-practice (master *+)] 
christie$ git submodule update --remote
Submodule path 'psychic-avenger': checked out 'fba086dbb321109e5cd2d9d1bc3b59478dacf6ee'
Submodule path 'scaling-octo-wallhack': checked out '88d66d5ecc58d2ab82fec4fea06ffbfd2c55fd7d'

Method 2: Checkout specific branch in submodule directory

In the submodule directory, checkout the branch you want with git checkout origin/branch-name:

[skade ;) ~/Work/submodule-practice/scaling-octo-wallhack ((b49591a...))] 
christie$ git checkout origin/REL_1
Previous HEAD position was b49591a... Cutting-edge changes.
HEAD is now at 88d66d5... Prep Release 1.

Either method will result will yield the following from git status:

[skade ;) ~/Work/submodule-practice (master *+)] 
christie$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	modified:   .gitmodules
	new file:   scaling-octo-wallhack

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   scaling-octo-wallhack (new commits)

Now let’s stage and commit the changes:

[skade ;) ~/Work/submodule-practice (master *+)] 
christie$ git add scaling-octo-wallhack

[skade ;) ~/Work/submodule-practice (master +)] 
christie$ git commit -m "Add scaling-octo-wallhack submodule, REL_1."
[master 4a97a6f] Add scaling-octo-wallhack submodule, REL_1.
 2 files changed, 4 insertions(+)
 create mode 160000 scaling-octo-wallhack

And don’t forget to push them to our remote repository so they are available for others:

[skade ;) ~/Work/submodule-practice (master)] 
christie$ git push -n origin master 
To git@github.com:christi3k/submodule-practice.git
   7e6d09e..4a97a6f  master -> master

(Note the -n flag means ‘dry run’, that is ‘do everything except actually send the updates.’ I recommend using this when available with commands that have potentially destructive results, including push and merge.)

Looks good, do it for real now:

[skade ;) ~/Work/submodule-practice (master)] 
christie$ git push origin master 
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 439 bytes | 0 bytes/s, done.
Total 3 (delta 2), reused 0 (delta 0)
To git@github.com:christi3k/submodule-practice.git
   7e6d09e..4a97a6f  master -> master

Removing a git submodule

Removing a submodule is a bit trickier than adding one.

Deinitialize

First, deinit the submodule with git submodule deinit :

[skade ;) ~/Work/submodule-practice (master)]
christie$ git submodule deinit psychic-avenger
Cleared directory 'psychic-avenger'
Submodule 'psychic-avenger' (git@github.com:christi3k/psychic-avenger.git) unregistered for path 'psychic-avenger'

This command removes the submodule’s confg entries in .git/config and .gitmodules and it removes files from the submodule’s working directory. This command will delete untracked files, even when they are listed in .gitignore.

Note: You can also use this command if you simply want to prevent having a local checkout of the submodule in your working tree, without actually removing the submodule from your main project.

Let’s check our work:

[skade ;) ~/Work/submodule-practice (master)]
christie$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean

This shows no changes because git submodule deinit only makes changes to our local working copy.

Running ls we also see the directories are still present:

[skade ;) ~/Work/submodule-practice (master)]
christie$ ll
▕ drwxrwxr-x▏christie:christie│4 day │ 4K│furry-octo-nemesis
▕ drwxrwxr-x▏christie:christie│16 sec │ 4K│psychic-avenger
▕ -rw-rw-r--▏christie:christie│4 day │ 29B│README.md
▕ -rw-rw-r--▏christie:christie│4 day │ 110B│README.mediawiki

[skade ;) ~/Work/submodule-practice (master)]

Remove with git rm

To actually remove the submodule from your project’s repository, use git rm:

[skade ;) ~/Work/submodule-practice (master)]
christie$ git rm psychic-avenger
rm 'psychic-avenger'

Let’s check our work:

[skade ;) ~/Work/submodule-practice (master +)]
christie$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD ..." to unstage)

modified: .gitmodules
deleted: psychic-avenger

These changes have been staged by git automatically, so to see what has changed about .gitmodules, use --cached flag or its alias --staged:

[skade ;) ~/Work/submodule-practice (master +)]
christie$ git diff --cached
diff --git a/.gitmodules b/.gitmodules
index dec1204..e531507 100644
--- a/.gitmodules
+++ b/.gitmodules
@@ -1,6 +1,3 @@
[submodule "furry-octo-nemesis"]
path = furry-octo-nemesis
url = git@github.com:christi3k/furry-octo-nemesis.git
-[submodule "psychic-avenger"]
- path = psychic-avenger
- url = git@github.com:christi3k/psychic-avenger.git
diff --git a/psychic-avenger b/psychic-avenger
deleted file mode 160000
index fdd4b36..0000000
--- a/psychic-avenger
+++ /dev/null
@@ -1 +0,0 @@
-Subproject commit fdd4b366458757940d7692b61e22f4d1b21c825a

So we see that in .gitmodules, lines related to psychic-avenger have been removed and that the psychic-avenger directory and commit hash has also been removed.

And a directory listing shows the files are no longer in our working directory:

christie$ ll
▕ drwxrwxr-x▏christie:christie│4 day │ 4K│furry-octo-nemesis
▕ -rw-rw-r--▏christie:christie│4 day │ 29B│README.md
▕ -rw-rw-r--▏christie:christie│4 day │ 110B│README.mediawiki

Removing all reference to the submodule (optional)

For whatever reason, git does not remove all trace of the submodule even after these commands. To completely remove all reference, you need to also delete the .git/modules entry to really have it be gone:

[skade ;) ~/Work/submodule-practice (master)]
christie$ rm -rf .git/modules/psychic-avenger

Note: This probably optional for most use-cases. The only time you might run into trouble if you leave this reference is if you later add a submodule of the same name. In that case, git will complain and ask you to pick a different name or to simply checkout the submodule from the remote source it already knows about.

Also, be careful with rm -rf because it doesn’t prompt you for a confirmation and there’s no dry-run flag.

Commit changes

Now we commit our changes:

[skade ;) ~/Work/submodule-practice (master +)]
christie$ git commit -m "Remove psychic-avenger submodule."
[master 7833c1c] Remove psychic-avenger submodule.
2 files changed, 4 deletions(-)
delete mode 160000 psychic-avenger

Looks good, let’s push our changes:

[skade ;) ~/Work/submodule-practice (master)]
christie$ git push -n origin master
To git@github.com:christi3k/submodule-practice.git
d89b5cb..7833c1c master -&gt; master

Looks good, let’s do it for real:

[skade ;) ~/Work/submodule-practice (master)]
christie$ git push origin master
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 402 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
To git@github.com:christi3k/submodule-practice.git
d89b5cb..7833c1c master -&gt; master

Updating submodules within your project

The simplest use case for updating submodules within your project is when you simply want to pull in the most recent version of that submodule or want to change to a different branch.

There are two methods for updating modules.

Method 1: Specify a branch in .gitmodules and use git submodule update --remote

Using this method, you first need to ensure that the branch you want to use is specified for each submodule in .gitmodules.

Let’s take a look at the .gitmodules file for our sample project:

[submodule "furry-octo-nemesis"]
  path = furry-octo-nemesis
  url = git@github.com:christi3k/furry-octo-nemesis.git
[submodule "psychic-avenger"]
  path = psychic-avenger
  url = git@github.com:christi3k/psychic-avenger.git
  branch = RELEASE_E
[submodule "scaling-octo-wallhack"]
  path = scaling-octo-wallhack
  url = git@github.com:christi3k/scaling-octo-wallhack.git

The submodule psychic-avenger is set to checkout branch RELEASE_E and both furry-octo-nemesis and scaling-octo-wallhack will checkout master because no branch is specified.

Edit .gitsubmodules

To change the branch that is checked out, update the value of branch:

[submodule "scaling-octo-wallhack"]
  path = scaling-octo-wallhack
  url = git@github.com:christi3k/scaling-octo-wallhack.git
  brach = REL_2

Now scaling-octo-wallhack is set to checkout the REL_2 branch.

Update with git submodule update –remote

[skade ;) ~/Work/submodule-practice (master *)] 
christie$ git submodule update --remote
Submodule path 'scaling-octo-wallhack': checked out 'e845f5431119b527b7cde1ad138a373c5b2d4ec1'

And if we cd into scaling-octo-wallhack and run branch -vva we confirm we’ve checked out the REL_2 branch:

[skade ;) ~/Work/submodule-practice/scaling-octo-wallhack ((e845f54...))] 
christie$ git branch -vva
* (detached from e845f54) e845f54 Release 2.
  master                  b49591a [origin/master] Cutting-edge changes.
  remotes/origin/HEAD     -> origin/master
  remotes/origin/REL_1    88d66d5 Prep Release 1.
  remotes/origin/REL_2    e845f54 Release 2.
  remotes/origin/master   b49591a Cutting-edge changes.

Method 2: git fetch and git checkout within submodule

First, change into the directory of the submodule you wish to update.

fetch from remote repository

Then run git fetch origin to grab any new commits:

[skade ;) ~/Work/submodule-practice/scaling-octo-wallhack ((b49591a...))] 
christie$ git fetch origin 
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 1), reused 3 (delta 1), pack-reused 0
Unpacking objects: 100% (3/3), done.
From github.com:christi3k/scaling-octo-wallhack
   e845f54..1cc1044  REL_2      -> origin/REL_2

Here was can see that the last commit for the REL_2 branch changed from e845f54 to 1cc1044.

Running branch -vva confirms this and that we haven’t changed which commit is checked out yet:

[skade ;) ~/Work/submodule-practice/scaling-octo-wallhack ((88d66d5...))] 
christie$ git branch -vva
* (detached from 88d66d5) 88d66d5 Prep Release 1.
  master                  b49591a [origin/master] Cutting-edge changes.
  remotes/origin/HEAD     -> origin/master
  remotes/origin/REL_1    88d66d5 Prep Release 1.
  remotes/origin/REL_2    1cc1044 Hotfix for Release 2 branch.
  remotes/origin/master   b49591a Cutting-edge changes.

Checkout branch

So now we can re-checkout the REL_2 remote branch:

[skade ;) ~/Work/submodule-practice/scaling-octo-wallhack ((88d66d5...))] 
christie$ git checkout origin/REL_2
Previous HEAD position was 88d66d5... Prep Release 1.
HEAD is now at 1cc1044... Hotfix for Release 2 branch.

Let’s check our work with branch -vva:

[skade ;) ~/Work/submodule-practice/scaling-octo-wallhack ((1cc1044...))] 
christie$ git branch -vva
* (detached from origin/REL_2) 1cc1044 Hotfix for Release 2 branch.
  master                       b49591a [origin/master] Cutting-edge changes.
  remotes/origin/HEAD          -> origin/master
  remotes/origin/REL_1         88d66d5 Prep Release 1.
  remotes/origin/REL_2         1cc1044 Hotfix for Release 2 branch.
  remotes/origin/master        b49591a Cutting-edge changes.

Commiting the changes

Moving back to our main project directory, let’s check our work with git status && git diff:

[skade ;) ~/Work/submodule-practice (master *)] 
christie$ git status && git diff
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   scaling-octo-wallhack (new commits)

no changes added to commit (use "git add" and/or "git commit -a")
diff --git a/scaling-octo-wallhack b/scaling-octo-wallhack
index 88d66d5..1cc1044 160000
--- a/scaling-octo-wallhack
+++ b/scaling-octo-wallhack
@@ -1 +1 @@
-Subproject commit 88d66d5ecc58d2ab82fec4fea06ffbfd2c55fd7d
+Subproject commit 1cc104418a6a24b9a3cc227df4ebaf707ea23b49

Notice that there are no changes to .gitmodules with this method. Instead, we’ve simply changed the commit hash that the super project is pointing to for this submodule.

Now let’s add, commit and push our changes:

[skade ;) ~/Work/submodule-practice (master *)] 
christie$ git add scaling-octo-wallhack

[skade ;) ~/Work/submodule-practice (master +)] 
christie$ git commit -m "Updating to current REL_2."
[master 5ddbe87] Updating to current REL_2.
 1 file changed, 1 insertion(+), 1 deletion(-)

[skade ;) ~/Work/submodule-practice (master)] 
christie$ git push -n origin master
To git@github.com:christi3k/submodule-practice.git
   4a97a6f..5ddbe87  master -> master

[skade ;) ~/Work/submodule-practice (master)] 
christie$ git push origin master
Counting objects: 2, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 261 bytes | 0 bytes/s, done.
Total 2 (delta 1), reused 0 (delta 0)
To git@github.com:christi3k/submodule-practice.git
   4a97a6f..5ddbe87  master -> master

what’s the difference between git submodule update and git submodule update –remote?

Note: git submodule update –remote looks at the value you have in .gitmodules for branch. If there isn’t a value there, it assumes master. git submodule update looks at your repository has for the commit of the submodule project and checks that commit out. Both checkout to a detached state by default unless you specify –merge or –rebase.

These two commands have the ability to step on each other. If you have checked out a specific commit in the submodule directory, it’s possible for it to be different than the commit that would be checked out by git submdoule update –remote specificied in the branch value of .gitmodules.
Likewise, simply looking at the branch value in .gitmodules does not guarentee that’s the branch you have checked out for the submodule. When in doubt, cd to the submodule directory and run git branch -vva. git branch -vva is your friend!

When a subbmodule has been removed

When a submodule has been removed from a repository, what’s the best way to update your working directory to reflect this change?

The answer is that it depends on whether or not you have local, untracked files in the submodule directory that you want to keep.

Method 1: deinit and then fetch and merge

Use this method if you want to completely remove the submodule directory even if you have local, untracked files in it.

Note: In the following examples, we’re working in another checkout of our submodule-practice.

First, use git submodule deinit to deinitialize the submodule:

[skade ;) ~/Work/submodule-elsewhere (master *)] 
christie$ git submodule deinit psychic-avenger
error: the following file has local modifications:
    psychic-avenger
(use --cached to keep the file, or -f to force removal)
Submodule work tree 'psychic-avenger' contains local modifications; use '-f' to discard them

We have untracked changes, so we need to use -f to remove them:

[skade ;( ~/Work/submodule-elsewhere (master *)] 
christie$ git submodule deinit -f psychic-avenger
Cleared directory 'psychic-avenger'
Submodule 'psychic-avenger' (git@github.com:christi3k/psychic-avenger.git) unregistered for path 'psychic-avenger'

Now fetch changes from the remote repository and merge them:

[skade ;) ~/Work/submodule-elsewhere (master)] 
christie$ git fetch origin 
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (1/1), done.
remote: Total 3 (delta 2), reused 3 (delta 2), pack-reused 0
Unpacking objects: 100% (3/3), done.
From github.com:christi3k/submodule-practice
   666af5d..6038c72  master     -> origin/master

[skade ;) ~/Work/submodule-elsewhere (master)] 
christie$ git merge origin/master 
Updating 666af5d..6038c72
Fast-forward
 .gitmodules     | 3 ---
 psychic-avenger | 1 -
 2 files changed, 4 deletions(-)
 delete mode 160000 psychic-avenger

Running ls on our project directory shows that the all of psychic-avenger’s files have been removed:

[skade ;) ~/Work/submodule-elsewhere (master)] 
christie$ ll 
▕ drwxrwxr-x▏christie:christie│3  hour│   4K│furry-octo-nemesis
▕ drwxrwxr-x▏christie:christie│5  min │   4K│scaling-octo-wallhack
▕ -rw-rw-r--▏christie:christie│3  hour│  29B│README.md
▕ -rw-rw-r--▏christie:christie│3  hour│ 110B│README.mediawiki

Method 2: fetch and merge and clean up as needed

Use this method if you have local, untracked (and/or ignored) changes that you want to keep, or if you want to remove files manually.

First, fetch changes from the remote repository and merge them with your local branch:

[skade ;) ~/Work/submodule-elsewhere (master)]
christie$ git fetch origin
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 1), reused 3 (delta 1), pack-reused 0
Unpacking objects: 100% (3/3), done.
From github.com:christi3k/submodule-practice
d89b5cb..7833c1c master -> origin/master

[skade ;) ~/Work/submodule-elsewhere (master)]
christie$ git merge origin/master
Updating d89b5cb..7833c1c
warning: unable to rmdir psychic-avenger: Directory not empty
Fast-forward
.gitmodules | 3 ---
psychic-avenger | 1 -
2 files changed, 4 deletions(-)
delete mode 160000 psychic-avenger

Note the warning “unable to rm dir…” and let’s check our work:

[skade ;) ~/Work/submodule-elsewhere (master)]
christie$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
(use "git add ..." to include in what will be committed)

psychic-avenger/

nothing added to commit but untracked files present (use "git add" to track)

No uncommited or staged changes, but the directory that was our submodule psychic-avenger is now untracked. Running ls shows that there are still files in the directory, too:

[skade ;( ~/Work/submodule-elsewhere (master)]
christie$ ll psychic-avenger/
▕ -rw-rw-r--▏christie:christie│30 min │ 192B│README.md

Now you can clean up files as you like. In this example we’ll delete the entire psychic-avenger directory:

[skade ;) ~/Work/submodule-elsewhere (master)]
christie$ rm -rf psychic-avenger

Working on projects checked out as submodules

Working on projects checked out as submodules is rather straight-forward, particularly if you are comfortable with git branching and make liberal use of git branch -vva.

Let’s pretend that scaling-octo-wallhack is an extension that I’m developing for my project submodule-practice. I want to work on the project while it’s checked out as a submodule because doing so makes it easy to test the extension within my larger project.

Create a working branch

First switch the the branch that you want to use as the base for your work. I’m going to use local tracking branch master, which I’ll first ensure is up to date with the remote origin/master:

[skade ;) ~/Work/submodule-practice/scaling-octo-wallhack ((1cc1044...))] 
christie$ git branch -vva
* (detached from origin/REL_2) 1cc1044 Hotfix for Release 2 branch.
  master                       b49591a [origin/master] Cutting-edge changes.
  remotes/origin/HEAD          -> origin/master
  remotes/origin/REL_1         88d66d5 Prep Release 1.
  remotes/origin/REL_2         1cc1044 Hotfix for Release 2 branch.
  remotes/origin/master        b49591a Cutting-edge changes.

[skade ;) ~/Work/submodule-practice/scaling-octo-wallhack ((b49591a...))] 
christie$ git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.

If master had not been up-to-date with orgin/master, I would have merged.

Next, let’s create a tracking branch for this awesome feature we’re going to work on:

[skade ;) ~/Work/submodule-practice/scaling-octo-wallhack (master)] 
christie$ git checkout -b awesome-feature
Switched to a new branch 'awesome-feature'

[skade ;) ~/Work/submodule-practice/scaling-octo-wallhack (awesome-feature)] 
christie$ git branch -vva
* awesome-feature       b49591a Cutting-edge changes.
  master                b49591a [origin/master] Cutting-edge changes.
  remotes/origin/HEAD   -> origin/master
  remotes/origin/REL_1  88d66d5 Prep Release 1.
  remotes/origin/REL_2  1cc1044 Hotfix for Release 2 branch.
  remotes/origin/master b49591a Cutting-edge changes.

Do some work, add and commit changes

No we’ll do some work on the feature, add and commit that work:

[skade ;) ~/Work/submodule-practice/scaling-octo-wallhack (awesome-feature)] 
christie$ touch awesome_feature.txt

[skade ;) ~/Work/submodule-practice/scaling-octo-wallhack (awesome-feature)] 
christie$ git add awesome_feature.txt 

[skade ;) ~/Work/submodule-practice/scaling-octo-wallhack (awesome-feature +)] 
christie$ git commit -m "first round of work on awesome feature"
[awesome-feature 005994b] first round of work on awesome feature
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 awesome_feature.txt

Push to remote repository

Now we’ll push that to our remost repository so others can contribute:

[skade ;) ~/Work/submodule-practice/scaling-octo-wallhack (awesome-feature)] 
christie$ git push -n origin awesome-feature 
To git@github.com:christi3k/scaling-octo-wallhack.git
 * [new branch]      awesome-feature -> awesome-feature

[skade ;) ~/Work/submodule-practice/scaling-octo-wallhack (awesome-feature)] 
christie$ git push origin awesome-feature 
Counting objects: 2, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 265 bytes | 0 bytes/s, done.
Total 2 (delta 1), reused 0 (delta 0)
To git@github.com:christi3k/scaling-octo-wallhack.git
 * [new branch]      awesome-feature -> awesome-feature

Switch back to remote branch, headless checkout

If we’d like to switch back to a remote branch, we can:

[skade ;) ~/Work/submodule-practice/scaling-octo-wallhack (awesome-feature)] 
christie$ git checkout origin/REL_2
Note: checking out 'origin/REL_2'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at 1cc1044... Hotfix for Release 2 branch.

Using this new branch to collaborate

To try this awesome feature in another checkout, use git fetch:

[skade ;) ~/Work/submodule-elsewhere/scaling-octo-wallhack ((1cc1044...))] 
christie$ git fetch origin 
remote: Counting objects: 2, done.
remote: Compressing objects: 100% (1/1), done.
remote: Total 2 (delta 1), reused 2 (delta 1), pack-reused 0
Unpacking objects: 100% (2/2), done.
From github.com:christi3k/scaling-octo-wallhack
 * [new branch]      awesome-feature -> origin/awesome-feature

If you just want to try the feature, checkout orgin/branch:

[2724][skade ;) ~/Work/submodule-elsewhere/scaling-octo-wallhack ((1cc1044...))] 
christie$ git checkout origin/awesome-feature 
Previous HEAD position was 1cc1044... Hotfix for Release 2 branch.
HEAD is now at 005994b... first round of work on awesome feature

If you plan to work on the feature, create a tracking branch:

[2725][skade ;) ~/Work/submodule-elsewhere/scaling-octo-wallhack ((005994b...))] 
christie$ git checkout -b awesome-feature 
Switched to a new branch 'awesome-feature'

Acknowledgements

Thanks GPHemsley for helping me figure out git submodules within the context of our MozillaWiki work. I couldn’t have written this post without those conversations or the notes I took during them.

Additional Resources

Update 19 Feb: Fixed typos and added ‘Additional Resources’ section.

Happy 10th Birthday, MozillaWiki!

Last Monday, Firefox turned 10 years old. Thunderbird turns 10 on 7 December.

This week we celebrate another birthday: MozillaWiki turns 10 on Wednesday, 18 November!

I’m immensely proud of our wiki, its ten year history, and of all the work Mozillians do to make MozillaWiki a hub of collaboration and a living memory for the Mozilla Project.

To show our appreciation for your efforts over the last decade, the MozillaWiki team has created a 10th Birthday badge.

MozillaWiki 10th Birthday Badge
MozillaWiki 10th Birthday Badge

All you need to do to join in the celebration and claim the badge is log in to MozillaWiki. Once you’ve done that, you’ll see a link to claim the badge at the top of the page. Don’t have a MozillaWiki account? No worries! Create one during this Birthday celebration and you can claim the badge too.

A bit of MozillaWiki history

Before I talk about all the good work we’ve done, and what we have planned for the remainder of this year and beyond, let’s take a quick stroll through the last 10 years. Thank you Internet Archive for hosting these snapshots of the wiki!

July 2004

The earliest snapshot I could find of the domain wiki.mozilla.org was from July 2004. It looks like we were hosting separate wiki installations, which may or may not have been Mediawiki.

wik.mozilla.org July 2004
wik.mozilla.org July 2004
wiki.mozilla.org/GeckoDev August 2004
wiki.mozilla.org/GeckoDev August 2004

November-December 2004

According to WikiApiary, the current installation of MozillaWiki was created on 18 November 2004. The closest snapshot to this date in the Internet Archive is 11 December 2004:

MozillaWiki December 2004
MozillaWiki December 2004

April 2005

By April 2005, the wiki had been upgraded, had a new theme (Cavendish), and had started using Apache rewrite rules to make the url pretty (e.g. no index.php).

Mozilla Wiki, April 2005
Mozilla Wiki, April 2005

August 2008

Three years later, in April 2008, we were still rockin’ the Cavendish theme and the Main Page had some more content, including links to the weekly project call that continues to this day.

MozillaWiki August 2008
MozillaWiki August 2008

December 2010

We started tracking releases in December 2007 (see version). Here’s what the Releases page looked like in December 2010.

MozillaWiki December 2010 Releases page
MozillaWiki December 2010 Releases page

May 2011

In May 2011, after 6 years of service, Cavendish was retired as the default skin and replaced with GMO.

MozillaWiki May 2011 - New GMO skin
MozillaWiki May 2011 – New GMO skin

July 2012

A year later, July 2012, MozillaWiki looked much the same.

MozillaWiki July 2012
MozillaWiki July 2012

July 2013

By July 2013, the Main Page was edited to include a few recent changes, but otherwise looked very similar.

MozillaWiki July 2013
MozillaWiki July 2013

August 2014

By August 2014, the revitalization of the MozillaWiki was in full swing and we were preparing for a major update to both the skin (GMO to Vector) as well as the underlying software (Mediawiki 1.19 to 1.23). We also had made significant changes to the content of the Main Page based on results of our recent user survey.

MozillaWiki August 2013
MozillaWiki August 2013

November 2014

Here’s what the wiki looks like today, 17 November, the day before it’s birthday. We’re running a slightly modified Vector skin and Mediawiki 1.23.x branch.

MozillaWiki November 2014
MozillaWiki November 2014

MozillaWiki today

Pages, visitors and accounts

As of 16 November, MozillaWiki has 115,912 pages, all public, and nearly 10k uploaded files. About 630 people per month, on average, log in and make contributions to the wiki. These include both staff and volunteers. Want to track these stats yourself? Visit Special:Statistics.

The number of daily visitors ranges from 9k-30k, with an average likely around 13-14k. Who are these visitors? According our analytics software we get visitors from all over the world, with the greatest concentration being from the US, Canada and UK.

The wiki has over 330,000 registered user accounts. I estimate that about 300k of these are inactive spam accounts, so the real number for user accounts is probably closer to 30,000.

What kinda of content is hosted on MozillaWiki?

All kinds of project activity is coordinated and recorded on the wiki. This includes activity related to our products: Firefox, Firefox OS, WebMaker, etc. It also includes community activities such as Reps, Firefox Student Ambassadors, etc. Most project activities have some representation on MozillaWiki. People also use the wiki to track projects and goals on an individual level. In this regard, it served as a place for Mozillians’ profiles long before we had mozillians.org.

The MozillaWiki isn’t setup for localized content now, but this hasn’t stopped our localized community from translating content. Every day a significant portion of account requests come from volunteers from regional communities and are often in a language other than English. In 2015, depending on resources available, we plan to significantly improve support for localized content on MozillaWiki.

2014 Accomplishments

This year we’ve made significant progress towards revitalizing MozillaWiki.

Accomplishments include:

  • Forming a team of dedicated volunteers to lead a revitalization effort.
  • Creating an About page for MozillaWiki that clarifies its scope and role in the project, including what is appropriate content and how to report issues.
  • Fixing years-old bugs that cause significant usability problems (table sorting, unavailability of Wikieditor, etc.).
  • Identifying a product owner for MozillaWiki and creating a Module for it, lead by a mix of staff and contributors.
  • Halting the creation of new spam and cleaning up significant amounts of spam content.
  • Upgrading Mediawiki from 1.19.x branch to 1.23.x branch AND changing the default theme without any significant downtime or disruptions to users.
  • Organizing a user survey and using those results to guide much of our roadmap, including the redesign of the Main Page and sidebar navigation.

Thank you everyone who has been a part of this work!

There’s still plenty to do, and many ways to contribute

We’ve made so much progress on the technical and infrastructure debt of MozillaWiki that we’re now ready to focus on improving content and collaboration mechnisms.

How can I help?

The are many ways you can help, and we have contribution opportunities for all kinds of skill levels and time commitments.

We’re working on documenting and organizing these contribution opportunities here: https://wiki.mozilla.org/MozillaWiki:Contribute so check that page often.

Join our mailing-list or community call

If you’d like to help us organize those opportunities, or have other ideas for improving the wiki, join one of our MozillaWiki Team communication channels or one of our community meetings. These meetings are held twice a month on Tuesday at 8:30 PST / 15:30 UTC. Our next meeting is 16 December. All who are interested in contributing to the wiki are welcome.

In the meantime, log in to MozillaWiki and celebrate its birthday with us by claiming the birthday badge!

Building a learning resource directory for Mozilla

The Learning Resource Directory (LRD) is a project (overview here) I’m leading to help organize and make discoverable all the information for learning about Mozilla and how to participate in our many projects. This post introduces the project, explains the current working prototype and gives information about how to get involved.

Why Mozilla needs a Learning Resource Directory

Mozillians have created a sizeable knowledge base over the project’s 15+ year history. We have a significant number of resources documenting and teaching the tools, policies, processes and procedures necessary for contributing to Mozilla.

Unfortunately for contributors, new and experienced alike, these resources are spread across a multitude of sources. These sources include websites, mailing-list archives, forums, blogs, social media, source code repositories, videos, and more. Some of these properties are hosted by Mozilla, others are not. Some are publicly available, others restricted to volunteers who have signed an NDA or are otherwise vouched and some are reserved for Mozilla paid staff.

What these resources have in common is the absence of a central index or directory that links them all together and makes them easily discoverable. It’s this gap that we’re addressing with the LRD.

As such, the goal of the Learning Resource Directory project is to provide an inclusive directory of all learning resources across Mozilla. The complete project plan, including timeline and KPIs is available here.

Strategy and approach

In order for directories of this sort to be successful, the information they provide needs to be: complete, current, relevant and contextual.

In order to be complete and current, Mozillians not only need to have the ability to contribute freely to the directory, but they also need to feel a sense of ownership and empowerment to ensure they become an integral, active part of its curation.

In order to be relevant and contextual, the data in the directory needs to be structured such that multiple views into the data can be created easily. That is, different learner types need different views of the directory. A new contributor who first requires basic competence of our essential communication tools presents a very different use case than an active contributor looking to branch out and work with a different team.

Related projects

Two related projects to the Learning Resource Directory are Webmaker’s Web Literacy Mapper and MDN’s Learning Area documentation plan.

How the LRD differs from these projects is that the LRD is specifically about learning resources related to contributing to Mozilla and as such serves a different, if at times overlapping audience. There will certainly be some overlap between what MDN covers as part of their Learning Area plan and what the web literacy mapper covers. However, there is a lot to learn with regard to web literacy skills that has nothing to do with contributing to Mozilla. The same applies to developing web apps and other knowledge areas that MDN covers.

Do you know of other related projects or efforts? Let me know!

MozillaWiki as the platform

Taking the requirements into consideration, MozillaWiki quickly came to mind as a possible platform for creating the index. Powered by Mediawiki, MozillaWiki is already set up in a way that anyone can participate in content generation and curation. This is demonstrated by a significant active contributor base (MozillaWiki has 600+ active daily users). And, the Semantic Mediawiki extension, already in use, provides a way to store and view data in a structured manner.

A prototype

So, I set about designing and implementing a prototype of the Learning Resource Directory. It’s far enough long that it’s now ready for people to take a look, try it out and provide feedback: https://wiki.mozilla.org/Learning_Resources

Prototype of Learning Resource Directory homepage.
Prototype of Learning Resource Directory homepage on MozillaWiki
Prototype of Learning Resource entry creation form.
Prototype of Learning Resource entry creation form.
Learning Resources-Contributing to the Mozilla codebase - MozillaWiki
Prototype of Learning Resource entry page/article. Wiki users can easily edit without needing to use wikitext by clicking ‘edit with form’ button.

Attributes of a learning resource

Each ‘learning resource’ has its own wiki page. Unlike regular wiki articles, these pages are created and edited in a guided way with a form. As such, any wiki user can create and edit learning resource pages without needing to know wikitext.

Each learning resource has:

  • Name: Name or title of the resource.
  • Description: Short description explaining what the resource is.
  • Link: Link to the resource.
  • MozillaWiki page: Corresponding MozillaWiki page, if there is one. Often a resource will have a wiki page explaining more about the project and how to contribute to it.
  • Learning Area (of interest): Each resource belongs to one of six learning areas of interest:
    • Mozilla history and culture,
    • Community Building
    • Essential Tools
    • Products and Projects
    • Communication Channels
    • Cross-functional Skills
  • Access info: Is this resource available to the public, Mozillians-only, or Staff-only?
  • Subject tags: This field is used to indicate corresponding functional, product and/or subject areas. Values are separated with commas.
  • Web literacies: Which web literacies does the learning resource teach?
  • Audience level: Novice, Intermediate and/or Advanced. Some resources will apply to multiple audiences.
  • Contributor level: New, Casual, Active and/or Core. Some resources will apply to multiple contributor levels.
  • Additional Details: a free-form field which can include information that doesn’t fit elsewhere

Try editing an existing resource or creating a new one.

Viewing data

Storing learning resource data in this way allows us to create different views for the data. Rather than creating these views with a static list of links that needs to be manually updated, we can create them with semantic media queries.

Here’s the beginnings of the learning resource index home page where resources are grouped by their learning area: https://wiki.mozilla.org/Learning_Resource_Index

Learning Resource Index - MozillaWiki - Pentadactyl_379
Prototype of learning resource index page.

And here’s an example of how a team might use queries of the learning resource index to create topic and audience-specific information such as new webdev contributors: https://wiki.mozilla.org/User:Ckoehler/Demos/Webdev_Get_Involved.

User:Ckoehler-Demos-Webdev Get Involved - MozillaWiki - Pentadactyl_380
Prototype of team page with resources selectively display for a specific audience (in this case new webdev contributors).

These examples may not look like much, but keep in mind that they are dynamically created based on which resources have been entered that match the given criteria. This means that as new resources are added, or old ones updated, these pages will be updated as well.

Please get involved, and how!

Try it out and give feedback

The easiest way to get involved is to take a look at the learning resource index prototype,  edit some entries, create some new ones and then leave feedback in one of these places:

  • on the bug
  • on the talk page for the project
  • or directly to me by irc or email

Note: You’ll need to have a MozillaWiki account and be logged in to edit and create resources. You may request an account if you don’t have one already.

If you’re feeling adventures, try and create some views using semantic mediawiki queries. I’m in the process of documenting how to do this here, or you can take a look at one of the demos, copy its code and experiment with modifying it.

Guiding questions

As you’re experimenting with the LRD and developing your feedback, please keep these questions in mind:

  • Is it easy to create and edit entries such that many people across the project will get involved in helping to maintain the directory? If not, what could be made easier?
  • Do the current fields make sense? Which fields are missing? Which are extraneous?
  • How can pages for each learning resource be formatted for best readability? E.g., are the fields in the right order? Would a table layout be better? Some some fields have color-coding?
  • How can pages presenting different views of the LRD be formatted for best readability?

Join a community call

Additionally, I’m hosting a set of community calls to gather input and organize volunteers. Here are the dates of the calls:

  • Monday, 17 November at 8:00 PST (16:00 UTC) via IRC
  • Tuesday, 18 November at 13:00 PST (21:00 UTC) via Vidyo
  • Thursday, 20 November at 17:00 PST (Friday, 2:00 UTC) via Vidyo CANCELLED if you were planning to attend this session, get in touch and we’ll reschedule
  • Tuesday, 25 November at 9:00 PST (17:00 UTC) via Vidyo
  • Tuesday, 25 November at 12:00 PST (18:00 UTC) via IRC

Connection details for Vidyo meetings:

Connection details for IRC meetings:

Please join if you have comments, questions, general feedback or otherwise want to be involved!

 

An Update from the MozillaWiki Team, including a report from Wikimania London

Last week we pushed a major upgrade to MozillaWiki, one that was months in the making. This post discusses the process of that upgrade and also talks about work the MozillaWiki Team did while together in London for Wikimania.

Who is the MozillaWiki Team?

The MozillaWiki team (formerly called the Wiki Working Group) is a mix of paid and volunteer contributors working to improve MozillaWiki. It is facilitated by MozillaWiki module owner (myself) and peers Gordon P. Hemsley and Lyre Calliope (both volunteer contributors).

Results from MozillaWiki user survey informs current roadmap

This summer, OPW (GNOME Outreach Program for Women) intern Joelle conducted a survey of MozillaWiki users. Much of our current roadmap is informed by the results of this survey, including re-organizing the Main Page, making information easier to find, improving the mobile experience and making editing easier.

If you’re interested in the results of that survey, watch her presentation Improving the Gateway: Mozilla Wiki User Research.

Why upgrade Mozilla Wiki now?

The primary motivation for this upgrade was to make current the version of MediaWiki, the software that runs MozillaWiki. Running a relatively older version of MediaWiki (1.19) prevented us from utilizing newer, beneficial features as well as useful extensions that require current versions of MediaWiki.

The Mozilla Wiki now utilizes MediaWiki version 1.23, and you can read about key features and improvements here: https://wiki.mozilla.org/MozillaWiki:News/2014-08/Upgrade_to_MediaWiki_1.23#MediaWiki_changes

This upgrade was carried out in two steps. The first was to change the default skin to Vector, which we did at the beginning of August. The second was to upgrade the software and require all users to use the new skin. This work we did last week.

Why did we choose Vector and drop support for all other skins?

Creating and maintaining MediaWiki skins is a complex and time-consuming process.

The two previous custom skins used on MozillaWiki were Cavendish and GMO. Already these themes, particularly GMO, were missing features available to users in officially supported skins. Our planned upgrade would make this disparity in user experience even greater. While planning the upgrade, we determined it didn’t make sense to expend resources keeping these skins tested and up to date, nor did it make sense to continue to offer a broken user experience just to maintain familiarity.

We selected Vector as the default skin because it is the one supported by MediaWiki itself and is thereby guaranteed to be stable and fully-featured. MonoBook is another theme supported by MediaWiki and we have left that enabled and available to use for those users who want an alternative look and feel. (You can make this change on your preferences page.)

Report from Wikimania London

As I mentioned, the MozillaWiki team has been preparing for and planning for this upgrade for several months. A small group of us gathered in London this August to have dedicated time to work together together and learn about MediaWiki and how to best utilize it at Mozilla by attending Wikimania, the annual MediaWiki community conference

The group included an even mix of paid and volunteer contributors who had been regularly participating in MozillaWiki team activities: Lyre Calliope, Jennie Halperin, Joelle F, Gordon P. Hemsley, C Liang and myself.

We spent the first two days hacking on MozillaWiki and the other three attending conference sessions and hacking together in between.

Having this rare time together in one place allowed us to get a lot done in a relatively short period of time.

Tasks we accomplished include:

  • updated sidebar (only visible in Vector and MonoBook)
  • created and deployed a new Main Page
  • roadmap planning through 2015 q1
  • planned and tested an upgrade to MediaWiki 1.23
  • continued to work on category planning

During the Wikimania conference, we accomplished the following:

  • learned about upcoming changes in MediaWiki, such as the new search extension (elastic search)  and visual editor
  • generated ideas for engaging new contributors across Mozilla projects, via targeted campaigns and directed play
  • generated ideas for recognizing different kinds of contributions leveraging badges and other projects at Mozilla
  • increased awareness of the Mozilla Wiki in the larger wiki community
  • learned about ways to enable real-time collaboration on the wiki
  • invited a number of Wikimedians to join Mozilla via the Wiki Working Group, CBT, and other areas

All of this information and collaboration helped us create our current roadmap.

Improvements planned for rest of 2014

We’re really proud of the work we’ve done on the Mozilla Wiki so far, but we’ve no intention to slow down yet. Improvements we’re planning to roll out this year, include:

  • [bugzilla bug_id=”1051201″] (to restore important feature to users and make wiki easier to use)
  • [bugzilla bug_id=”1051189″] (to provide a mobile-friendly interface)
  • [bugzilla bug_id=”915187″]
  • [bugzilla bug_id=”1051204″]
  • [bugzilla bug_id=”1051206″]
  • [bugzilla bug_id=”1064994″]

An invitation to Participate

We hope you’re liking our work on MozillaWiki so far! We invite all those who would like to contribute to the wiki to join our regular MozillaWiki team meetings which are every other Tuesday at 8:30am PT (15:30 UTC). Our next meeting is 16 September. Participation details.

Driving Project-wide Community Growth by Improving the Mozilla Wiki

At the Mozilla project there are many ways to contribute. Some contributions are directly to our products: Firefox Desktop, Firefox for Android, Firefox OS, Webmaker, etc. Some contributions are to things that make those products better: QA, localization, release engineering, etc. Some contributions are to tools that help us work together better, such as: Pontoon, Bugzilla, Mozillians and the Mozilla Wiki.

I’ve long had a personal interest in the Mozilla Wiki. When I started as a paid contributor in 2011, it was my main source of information about the many, many Mozilla projects.

And I’m not alone in this. Contributor Sujith Reddy says:

The wiki page of Mozilla has got info about every project running around. For instance, being a Rep, I get questioned by many people on mails, What exactly is the ReMo program. I would reply’em with a single link: https://wiki.mozilla.org/ReMo Basically, it makes my work easier to explain people. It is Mozilla-Encyclopedia :)

And contributor Mark A. Hershberger says:

Wikis provide the best way for a community with many members to collaborate to disseminate knowledge about their shared interest…The wiki provides one of the easiest ways to start contributing to the shared work and become a contributing member of the Mozilla community.

And it’s not just volunteer contributors who find the wiki essential. Here’s Benjamin Sternthal from Web Production:

The Mozilla Wiki is an essential part of how Web Productions manages projects and involves community. The Wiki is particularly valuable for our project hubs, the central place where anyone can view information about a project without having to hunt around in various systems.

History of the Mozilla Wiki

The Mozilla Wiki has been around for a long time. According to WikiApiary it was founded on in November of 2004 making it nearly 10 years old! It has over 90,000 pages, all of which are public, and roughly 600 daily users.

During most of its existence the Wiki has been maintained by community without organized effort. Mozilla IT has supported it on Mozilla’s corporate infrastructure, and various community members, paid and volunteer, have worked to keep it as up-to-date and functional as possible.

This approach worked fairly well for a long time. But during the last couple of years, as our community has experienced incredible growth, this ad-hoc approach stopped serving us well. The wiki has become harder and harder to use when it should become easier and easier to use.

Formation of the Wiki Working Group

And that’s why a group of us came together in March 2014 and formed the Wiki Working Group. It’s been a few months and the group is going very well. We meet twice a month as a full group, and in smaller groups as needed to work through specific issues. There are 25 people on our mailinglist and meeting attendance averages 8-12, with a mix of paid and volunteer contributors in about a 1:1 ratio. Of the paid contributors, I am the only with time dedicated to work on the Wiki.

In a short amount of time we’ve made some significant accomplishments, including:

  • triaged all open bugs (>100, some open several years without updates)
  • created a formal governance structure by creating a submodule for the Wiki within Websites
  • reduced the clutter and improved usability on the wiki by eliminating new spam (spam accounts and pages previously numbered in the several hundreds per day on average)
  • improved usability of the wiki by fixing a few critical but long-standing bugs, including an issue with table sorting
  • created an About page for the Wiki that clarifies its scope and role in the project, including what is appropriate content and how to report issues

One of the long-standing bugs was to re-enable the WikiEditor which greatly improves usability by giving users an easy-to-use toolbar to allow page authoring without having to know wiki markup.

Chris More from Web Productions gave us this feedback on these recent changes:

With the re-introduction of the visual wikieditor, it has allowed non-technical people to be able to maintain their project’s wiki page without having to learn the common wiki markup language. This has been invaluable with getting the new process adopted across the Engagement team.

We’ve also worked hard to create a clear vision for the purpose of the Wiki Working Group. Early on we reached consensus that it is not our role to be the only ones contributing to the wiki. Rather, it is our role to enable everyone across the project to feel empowered to participate and collaborate to make the Mozilla Wiki an enjoyable and lively place to document and communicate about our work.

Where we’re going in 2014

With that in mind, we’re working towards the following milestones for this year:

  • increasing usability and stability) upgrading to current version of Mediawiki
  • updating the default skin (theme) to be more usable and mobile-friendly
  • improving the information architecture of the site so content is easier to find and maintain
  • engage contributors to learn to use the wiki and help us improve it by running a series of “wiki missions”
  • create compelling visual dashboards that will help us better understand and recognize wiki activity

We expect these changes to increase participation on the wiki itself considerably, and to increase community activity in other areas of the project by making it easier to document and discover contribution pathways. In this way, the WWG serves all teams at Mozilla in their community building efforts.

Chris More from Web Production again:

The use of the wiki has recently been amplified by the introduction of the Integrated Marketing process. The new process is essentially program management best practices to ensure what Engagement is working on is relevant, organized, and transparent. The wiki has been used to document, share, and to be the hub for both the process and every major project Engagement is working on. Without the wiki, Engagement would have no central public location to share our plans with the world and to understand how to get involved.

So, while our group is small, we are highly engaged. As we continue our work, we’ll enable many, many more people to become contributors and to continue contributing across the project.

How to Get Involved

If you’re interested in joining or following the Wiki Working Group, take a look at the How to Participate section on our wiki page for links to our mailinglist and meeting schedule.

If you have general feedback about the Mozilla Wiki, or things you’d like to see improved there, leave comments on this Sandbox page.

It’s the 4th of July and I’m Celebrating Independence from Facebook

I just requested that Facebook permanently delete my account.

This change is a long time coming. I’ve grown increasingly concerned about the power Facebook exercises to commodify and influence our social interactions. There’s nothing holding Facebook accountable in the exercise of this power. Aside from all of that, I get very little out of time spent on the site. Yes, it’s a way I can connect with some folks for which I’m not in the habit of calling, emailing or writing. There’s nothing stopping me from doing this, however. I have the phone numbers, emails and addresses of the folks I generally care about keeping in touch with. I do wish more folks had their own blogs, though.

Earlier in the week I posted a message on my timeline telling folks that in a few days I’d be deleting my account. I listed a few other ways to get in touch with me including twitter, my blog, and email. The other thing I did was look at the settings for every Facebook page I’m an admin on and ensure I wasn’t the only one (I wasn’t). I also downloaded a copy of my info.

Today I logged in, ready to delete my account. First I couldn’t find a way to do so. I noticed a “deactivate my account” link under security settings. I figured this was the only way, so I tried it first.

When you try to deactivate your account, Facebook presents you with a page that does everything to try and get you to keep your account active. It shows you pictures of your friends, says they will miss you and prompts you to message them. I found it particularly funny that one of the friends it showed me was Creepius the Bear (and identity created to demonstrate how creepy one can be on Facebook):

Creepius will miss me after I've left Facebook.
Creepius will miss me after I’ve left Facebook.

And then after this you must provide a reason you’re deactivating your account. For any reason you select, you’re given additional information that supposedly resolves the concern:

Facebook wants to know why you're deactivating your account.
Facebook wants to know why you’re deactivating your account.

What caught my attention was the Email opt out option, which states:

Note: Even after you deactivate, your friends can still invite you to events, tag you in photos, or ask you to join groups.

Not what I wanted, so I started figuring out how to work around this. Unfriend everyone first? Sounds tedious. Then someone asks me in IRC, “why don’t you delete instead of deactivate?” I responded saying I didn’t know that was an option. So, I searched Facebook’s help for “deactivate my account” and found this help page: How do I permanently delete my account?

I follow the link in that article, and got this prompt:

Deleting my facebook account.
Deleting my facebook account.

Much nicer, right? No guilt-trips and attempts to invalidate address my concerns. I clicked “Delete My Account”, filled out my password and captcha and got the following confirmation:

Confirmation that my account has been deactivated and will then be deleted
Confirmation that my account has been deactivated and will then be deleted

I also received confirmation via email.

So, that’s it! Assuming I don’t log in to my account during the next 14 days, my account will be deleted. Ah, freedom!

If you like the idea of doing this, but want a more gradual approach, check out de-facing, in which one person talks about their plan to leave Facebook one friend at a time.

Some OpenID Providers

While I don’t hear about it a lot recently these days, there are still some sites that I need OpenID to log in to. I had been using myOpenID from Janrain for this, but that service was retired. Unfortunately, So was my backup provider, ClaimID.

So, I went shopping for new providers! Here’s what I found:

Whatever OpenID provider you have, I highly suggest setting up delegation. OpenID delegation means you can use any website you control as your OpenID login. The delegate website is configured to use your chosen provider and you can switch anytime without having to update your login information on other sites.

How do you set up delegation? It’s easy! You just have to add the following two lines to the head of the site you want to act as delegate:

<link rel="openid.delegate" href="http://mywebsite.com/" />
<link rel="openid.server" href="https://myopenidprovider.com/" />

Replacing “mywebsite.com” with the site you want to act as delegate, and “myopenidprovider.com” with your chosen OpenID provider (e.g., openid.stackexchange.com). Make sure you have an account at the OpenID provider of your choice before doing this.

If you have a self-hosted WordPress blog, you can use this plugin instead of editing your theme files.

Thanks Aaron Parecki, Nicolas Ward, and Sumana Harihareswara ‏ for helping me compile this list. Know of an OpenID provider not already on the list above? Let me know in the comments!

Changes to Mozilla Wiki: New users must request accounts

Update 9 June 2014: To clarify, only those who wish to edit the Mozilla Wiki need to request an account. You do not need an account to read the wiki.

Note: The FAQ below is also available on the Mozilla Wiki at MozillaWiki:Accounts.

For some time now the Mozilla Wiki has been significant amounts of spam. To give you an idea of the magnitude of the problem: hundreds of spam accounts are created every week and a handful of admins each spend upwards of 4 hours per week identifying and deleting spam content and accounts.

To combat this problem, we have have implemented a change to the way user accounts are created.

Prior to this change, anyone could create an account and immediately start editing pages. After a short interval, a new user was then able to create pages as well.

Now, all new users are required to request an account and have that request approved prior to logging in and editing or creating pages.

We expect the impact of this change to valid users to be minimal. During a typical week, only a handful of legitimate user accounts are created. The rest are spam.

Below you’ll find a list of questions and answers to help aid in this transition. If you have any questions that we have not answered, please let us know.

Thank you to everyone who helped implement this change, including: Jake Maul, Jason Crowe, AlisonW, KaiRo, and Gordon Hemsley, as well as all those who agreed to help approve accounts.

FAQ

What is the work-flow for new users?

The new work-flow for new users is as follows:

  • A user visits the Mozilla Wiki and clicks Log in / create account
  • Users that don’t already have an account will click request one
  • On the request account page, the user will enter their preferred username, email address, name, bio, and additional information about themselves (optional).
  • After the user submits their request, they will receive an email asking them to confirm their email via a link. The user clicks on that link and their email is then confirmed.
  • Once the user’s request is approved, they will receive an email notification that includes a temporary password. They will be required to change their password the first time they log in to the wiki

Is the work-flow different for users who have accounts already?

No, those users will login as they always have.

What is the new work-flow for bureaucrats?

  • Once the user has confirmed their email, a notice of the request is sent to designated wiki users (a notice is also included on the RecentChanges and Watchlist pages for users who have the ability to approve).
  • The bureaucrat reviews the user’s account request and takes one of the following actions: approves, holds, or denies. Bureaucrats are instructed to approve all users they can reasonable verify are people with legitimate reason to edit the wiki (that is, not spammers or bots).

What should I do if my request has not been approved withing 24-48 hours?

Please email wikimo-admins@mozilla.org or find us on IRC in #wiki.

What should I do if I am involved in a Mozilla-related event which is likely to generate many timely user account requests?

Please email wikimo-admins@mozilla.org or find us on IRC in #wiki to let us know. We’ll do our best to have someone on hand during your event to approve requests.

Alternatively, we can create accounts for users ahead of time.

Why am I still encountering spam on the wiki?

The volume of spam received by the Mozilla Wiki has been such that we’ve not always be able to keep up with it. The change we have made to new user account creation affects the creation of new spam, but does not address preexisting spam content. We will continue to work on identifying and removing content. If you see a page that is clearly spam, let us know via IRC in #wiki.

How can I get involved with improving the Wiki?

The best way to get involved with improving the wiki is to join the Wiki Working Group (and we’d love to have you!).

Note: This FAQ also available on the Mozilla Wiki at MozillaWiki:Accounts.