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.
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!
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.
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:
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).
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.
In May 2011, after 6 years of service, Cavendish was retired as the default skin and replaced with GMO.
A year later, July 2012, MozillaWiki looked much the same.
By July 2013, the Main Page was edited to include a few recent changes, but otherwise looked very similar.
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.
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.
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.
This year we’ve made significant progress towards revitalizing MozillaWiki.
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.
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!
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.
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.
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,
Products and Projects
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.
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.
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.
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
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:
Vidyo Room: ckoehler, 9597
Via Telephone: +1 650 903 0800, x92 (or +1 800 707 2533, password 369). Then 99597. Press •1 to mute if you’re dialed in (creates audible beep).
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.
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)
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.
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.
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?
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 email@example.com 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 firstname.lastname@example.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!).
The community building curriculum subgroup had its first meeting (notes)! During the meeting we brainstormed what kind of community building curriculum could be possible to roll-out this year. We agreed that finding existing curriculum and adapting for Mozilla would be the best way to utilize our limited resources. Between this meeting and next, we’re going to make a list of possible resources to adapt
A community building skills question is prepared in Mozilla Moderator and after seeing with responses from the MozCamp design session in April, I’ll announce project-wide and ask for Mozillians to submit their ideas.
As always, you are welcome to join me in any of these projects. Look at my mozillians profile for the best way to get in touch with me.
One issue to emerge for last December’s Community Building meet-up was how important the Mozilla Wiki is to the project and also how neglected a resource it is. The Wiki Working Group was formed to address this issue. Since then, the Mozilla Wiki has become an official sub-module of Websites, we’ve fixed a handful of long-standing bugs, and we’re working on short- and long-term roadmaps for the wiki.
During our discussions about the wiki, we discovered the need for a clear statement about the purpose of the wiki, its role and importance to the project, what content belongs on the wiki (vs MDN, vs SUMO, etc.), and its governance structure. As such, we have drafted an About page that attempts to do those things.
We’d like for as many Mozillians as possible to read our draft and comment on it. When reviewing, we ask you to consider the following questions:
what about the content does or does not make sense to you?
what about the content does or does not resonate with you?
to what extent does the content match your vision for wiki.mozilla.org?
to what extent can you support the purpose, scope and governance structured described?
The comment period is open until 26 May 2014 at 14:00 UTC. Those comments will be considered and incorporated and this page adopted into the wiki by 15 June 2014.
Thank you to everyone from the Wiki Working Group who contributed to this document, especially: Lyre Calliope, Gordon Hemsley, Justin Crawford, Larissa Shapiro, Jennie Rose Halperin, Mark A. Hershberger, and Jason Crowe.