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:

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.

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:

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:

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:

(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.)

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.

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:

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.

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

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:

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.

[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

Share this:

Update 12/31 1:30pm PT: WE DID IT!! Nearly 100 of you donated over $8,500.00 and another donor has offered the difference needed to match Sumana’s $15k. Thank you so much everyone! We’re looking forward to an amazing 2015.

Update 12/26 5pm: We’re at 25% of our goal! Not bad, but still a ways to go. Take a moment to pitch in a few bucks?

Me, working registration desk at OSBridge 2010. Photo by @igalko.

I moved to Portland from San Francisco in the Fall of 2007. I decided to move here after only two or three visits (all in the late Summer) on nothing more than a strong intuition that it was the place I needed to be. That intuition turned out to be right and Portland has ended up being the place where I put down roots, where I’ve grown up to be an adult, and where I feel most connected to and supported by others.

There are a lot of reasons why Portland ended up playing this role in my life, chief among them being the awesome local tech community.

I first got involved with the tech community by attending user groups. Because so many groups were hosted at Cubespace at that time, I was able to drop in on other groups and meet many folks. At some point I started volunteering, first for BarCamp, then Ignite (or was it the other way around?) Next I volunteered for a significant role at Open Source Bridge, which also provided my first conference speaking opportunity,

My career developed in lockstep with my involvement in the Portland tech community. I’ve grown as a programmer and technologist because through the community I’ve had access to skilled peers and mentors. Every job I have gotten since I moving here, including my current one at Mozilla, I’ve gotten because of someone I had a relationship with through the community. Being involved with the tech community has given me opportunities to practice and develop leadership skills, which continues to benefit both my professional and my personal life. I can honestly say I’m a better, more responsible person because of my involvement in Portland tech. Lastly, and most importantly, I’ve made my closest and dearest friends through the community and my work in it.

Syndicate co-founders with former Mayor Sam Adams. Photo by @reidab.

These are the personal reasons why I was motivated four years ago to co-found the Stumptown Syndicate with Reid Beels and Audrey Eschright. They are the reasons why I continue today to give so much of my free time as a Director of the Syndicate. I believe in Portland tech and its ability to support and empower individuals and make their lives better.

I’m proud of the work we’ve done over the last four years. Highlights include:

Bootstrapping a non-profit organization and successfully applying for 501(c)(3) status.

Hosting four successful Open Source Bridge events, three BarCamps, four WhereCamps, and a handful of IgnitePortland events. All of these events are free to attendees, or in the case of Open Source Bridge, have the option of volunteering in exchange for free attendance. The value of these events lies in the community connection they allow and the resulting personal and professional growth opportunities.

Creating the Citizen Code of Conduct and adopting it for all of our events. The CCoC has been adapted and adopted by many other events as well.

Increasing the speaker diversity of Open Source Bridge. In 2014, we accepted 50% woman speakers and 20% non-White speakers.

Hosting and guiding development on open source projects OpenConferenceWare and Calagator.

Stumptown Syndicate is almost entirely volunteer-run. None of the Board members, including myself, is paid and we all have full- or near-full-time jobs elsewhere. We don’t have an Executive Director or any other staff. We rely on the generosity and dedication of participants, volunteers and other community members in order to do our work.

Open Source Bridge registration and info desks

That’s why our end-of-year fundraising campaign is so important. If we are able to fully match Sumana’s $15k contribution, we’ll start the year off with an additional $30k in the bank. This is huge for our tiny organization which operates on an average of $110k a year. $30k represents an additional 27% operating capital to us! With this money we can establish a travel fund so that we can bring more high-quality, diverse speakers to Open Source Bridge and other events. With this money we can start saving for our very own community space. With this money we could host a full BarCamp event at the Eliot Center again. With this money we can host more Calagator code sprints. With this money we can hire the resources needed to post audio and video from Open Source Bridge faster than 6 months after the conference. With this money we can provide childcare at more of our events. With this money we can add captioning and/or transcripts to Open Source Bridge talks.

All that’s needed for us to earn this $30k and have it be available to us is for you all to contribute half of it. $15k may sound like a lot, but it’s totally doable. Look at it this way, if everyone who’s ever attended one of our events gave $10, we’d blow right past the goal.

So, please, if you’ve been to one of our events and it’s meant something to you, donate.

If you want to see more awesome community-led, volunteer-run activities, donate.

Most of you reading this probably have $10 to spare. Some of you significantly more than that. If you can give 5 bucks, please do so. Those of you who can swing $100 please do so.

With every dollar you give you let us know that our work matters to you. It’s a vote of confidence as well as a resource we can use to do even more for you.

Stumptown Syndicate is a 501(c)(3) non-profit and so your donations are tax-deductible in the US.

Have you already given or are you about to? Many employers will match your donations to 501(c)(3) dollar-for-dollar. Make your donation count for three times as much by asking your employer if they offer this. (OPB has an extensive list of employers with matching programs.)

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

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 2004wiki.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

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

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.

December 2010

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

July 2012

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

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

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

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 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.

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!

Share this:

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

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

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?

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.

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:

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 VidyoCANCELLED if you were planning to attend this session, get in touch and we’ll reschedule

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.

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.

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

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.

Share this:

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.

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 :)

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.

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.

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.

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.

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.

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

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.

Share this:

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.

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:

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.

Share this:

Yesterday, nearly four years after our religious ceremony, Sherri and I became legally married. I am so incredibly happy and proud to be able to call Sherri my legal spouse, and me hers, with all the rights and responsibilities therein.

Christie’s mom Laura reads a few words.

The ceremony was brief, at our home, with a few clothes friends and family members in attendance.

These are the words I spoke to Sherri:

Not quite 7 years ago, I set out for Portland to start a new part of my life. Someone, or something must have been aware of my plan, because I was guided to you shortly upon my arrival here.

Since then I have learned that you are one of the most generous, compassionate and courageous spirits I have ever met. From the beginning, you opened your heart wide to me and while cautious at first, I have learned to take great refuge in your presence.

As many here know, the last handful of years together has been difficult. But between the challenges we’ve faced, we’ve found space for joy, laughter, and delight. I would do everything all over again for the privileged of getting to build this life with you.

My vows to you:

Because our life together will not always be easy, I vow to meet challenges in our relationship with a sense of compassion and adventure.

Because our family is but one piece in a very large puzzle. I vow to live a life of service to you, to our marriage and to our community.

Because while love is not scarce, many resources are, I vow to make sure you always have the things you need most such as food, water, shelter and art supplies. I vow to utilize our resources wisely.

Because I want to spend the most amount of time possible with you and grow old together, I vow to care for my body and mind.

Because play is just as important as work, I vow to cultivate playfulness, laughter and lightness in our relationship.

Because what I was hiding, deep inside, you brought out into the light, and even thought it is terrifying at times, I vow to stand bravely in the light of your love.

My dearest Sherri, You are the first person who made me truly feel loved. I look forward to sharing a life of practice with you and I am truly honored that you are recognizing again this commitment with me here today, in front of our friends and family.

While I wish we didn’t have to wait at all to get legally married, I’m grateful we have been able to do so in our home state earlier than I had anticipated. I’m grateful for the opportunity affirm “yes, I know what these vows mean in practice and I continue to commit to every single one of them.”

The Ursula K Le Guin quote that Sherri sent out with our invitations says it all:

Love does not just sit there, like a stone; it had to be made, like bread, remade all the time, made new.

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.

What is the work-flow for new users?

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!).