Tag: wwg

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.

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.

Community Building Education Update – 12 May 2014

Education & Culture Working Group

Wiki Working Group

  • Held our regular working group meeting on 6 May (notes).
  • Discussed group feedback on the draft scope and mission statement for both the Mozilla Wiki and the WWG itself.
  • Finalized About wiki.mozilla.org statement and posted for feedback. See announcement for background and please comment!

Community Building Curriculum Subgroup

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

Get Involved

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.

Upcoming meetings

Calendar file for both meetings: ics or html.

Scope and Mission of wiki.mozilla.org — feedback wanted

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.

Please make comments directly on the draft About wiki.mozilla.org.

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.

Community Building Education Update – 5 May 2014

This doesn’t fit specifically in either category below, but I still wanted to call attention to it: Last Tuesday we launched Firefox 29 “Australis,” our biggest redesign of Firefox since version 4!

Education & Culture Working Group

  • Further planning with Dino Anderson about diversity & inclusion efforts we’d like to roll out this year. I don’t have notes I can share, but will work on putting together some kind of update soon.
  • Drafted an open planning checklist (comments welcome!). This is geared towards all Mozilla teams (of paid and volunteer contributors) to help them adopt and maintain an open planning process.
  • Represented the E&C Working Group at the Grow Mozilla meeting.
  • Facilitated our regular Education & Culture working group meeting (notes).

Wiki Working Group

  • Triaged all open Websites::wiki.mozilla.org bugs. Closed 43 bugs (search).
  • Setup the wiki as a project in scrumbugs. Still updating bugs with user stories, so you won’t see a lot there, except in the backlog.
  • Worked, with Lyre and Larissa, on final drafts of wiki.mozilla.org and WWG purpose and scope documents. We’ll review as a group tomorrow and then I’ll post publicly.

Other

  • I wrote a tiny, simple WordPress plugin called bz shortcode to help make generating individual bugzilla.mozilla.org links on this blog easier.
  • I’m trying to attend fewer meetings so that I have more time to work. My strategy so far is: If I receive a meeting invite without an agenda item making it clear why I’m a necessary participant, I’ve started declining with a note to the organizer asking if I really need to be there. The flip side of this is that I’m doing my best to have clear agendas a head of time for the meetings that I facilitate.

Priorities for this week

  • Finalize scope documents for both the wiki itself and the wiki working group.
  • Update contribute area page for webdev.
  • Outline requirements for project-wide “Mozilla Quilt” (part of Education roadmap). Working on this with Dino and others.
  • Expand the brainstorm of needed community building skills that we started at last month’s MozCamp planning session to entire organization using Mozilla moderator.
  • Collect feedback on open planning checklist and publish.

Get Involved

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.

Upcoming meetings

Calendar file for both meetings: ics or html.

Community Building Education Update – 29 April 2014

Note: This is the first in what I plan to be weekly updates about the work we’re doing as part of the Education and Wiki Working Groups, part of the community building team at Mozilla. I’ll tag these updates with mozilla as well as cbt-education and wwg when appropriate.

Wiki Working Group

On Tuesday of last week we help our twice-monthly Wiki Working Group meeting (notes). Key takeaways:

  • We celebrated becoming an official sub-module of websites.
  • We talked about planning an in-person meet-up and sprint at this year’s Wikimania in London.
  • We talked about the need to clarify our vision for the wiki as a prerequisite for creating the long-term roadmap, as well as the need start on a short-term roadmap to address critical needs.

During our next meeting we’ll continue work on both the short- and long-term roadmaps. If you’re interested in contributing, please get involved!

Later in the week, a few of us fixed the following bugs:

  • Bug 858844 – Sortable tables on wiki no longer sortable
  • Bug 1001710 – Recent changes to wiki.mozilla.org break bugzilla plugin
  • Bug 819708 – wiki.mozilla.org editor wont show rich text editor

MozCamp Planing Session

Last week a handful of contributors gathered at the San Francisco office to plan MozCamps 2014, the next phase of what we’re still calling “MozCamps” but which we plan to evolve into a new kind of event.

I’m still synthesizing everything we covered during the planning session, but the most relevant takeaway in terms of the education working group was this list of community building skills that the group generating during a brainstorming session about what content should be included in the new MozCamps. This week I’m working to integrate that list into the existing community building curriculum roadmap.