Comments on this document are now closed. Feedback has been incorporated and the new MozillaWiki:About is now live.

Purpose

This wiki (wiki.mozilla.org, AKA MozillaWiki or WikiMO) is the official public wiki of the Mozilla Project. It serves as the public memory for the Mozilla community, documenting its projects, planning, processes and teams. Additionally, the wiki seeks to facilitate lively community interaction that empowers contributors to coordinate activities, find support, and make their projects accessible to other contributors across Mozilla.

This wiki is a publicly available resource for those wanting to learn more about the Mozilla Project. It is not designed nor intended for end-users. If you're looking for user support for any of Mozilla's products, visit support.mozilla.org.

What content is appropriate for the Wiki?

• Any content that is related to the on-going planning, coordination or other contribution activities of current or past Mozilla projects.
• Any content pertaining to Mozilla's mission, strategy or history.
• Any content that supports Mozilla's mission or community.
• Any content related to the discussion of content on the wiki (e.g. Talk/Discussion pages).
• Any content that is related to helping people use the Wiki.

Content appearing to be completely unrelated to Mozilla and not falling into any of the categories above may be deleted as spam or moved elsewhere.

Is product documentation appropriate for the Mozilla Wiki?

In general, no, product documentation is not appropriate for the Mozilla Wiki except when it is about the Mozilla Wiki itself.

There are two types of product documentation: end-user documentation and developer-focused documentation.

End-user documentation is written for users of Mozilla's products and explains how are products work and how to use them. In general, this type of content belongs on SUMO.

Developer-focused documentation is written for programmers and includes content such as technical reference information and building and debugging instructions. In general, this type of content belongs on MDN.

To summarize: MDN documents how to interact with code. The Mozilla wiki documents how to interact with teams. SUMO documents how to interact with Mozilla products (as an end-user).

Who own and maintains the Mozilla Wiki?

The wiki is owned and maintained by the Mozilla community.

• Infrastructure for the wiki is provided by Mozilla Corp.
• Governance issues are managed by the WikiMo module, a sub-module of Websites. Its current module owner is Christie Koehler and module peers are Lyre Calliope and Gordon Hemsley.
• Technical Support is provided jointly by the community and MoCo staff.
• Content is managed by the community. Information here is public and can be modified by anyone in the Mozilla community with sufficient interest and knowledge to improve it (and an account).

Where can I report issues with wiki.mozilla.org?

• Technical issues should be reported via bugzilla. These include server or client-side errors, styling issues, problems with accounts or logging in, and feature requests.
• Content issues should be addressed on the wiki itself using Talk/Discussion pages whenever possible.

General questions can be addressed to tools-wiki or #wiki on irc.mozilla.org.

How is the Wiki a critical resource to the Mozilla Project?

The Wiki provides the most comprehensive, overall picture of Mozilla's mission, strategy, and history. Information on the wiki tells the story of Mozilla and makes the organization navigable in a way that no other single resource does. The wiki, along with Bugzilla and our forums, form the core of Mozilla's long-term institutional record.

The Wiki is a significant entry point for contributors into the Mozilla project. It serves as a primary and massively scalable on-boarding tool because it provides the opportunity for self-serve contribution pathways across all areas of the project. The wiki enables self-motivated individuals to take advantage of contribution opportunities immediately. The better organized the wiki, the more people are able to take advantage of these opportunities.

Publicly available wikis, code repositories, and bug trackers are essential to our collaborative environment and connect our project to the greater open source eco-system. These tools are part of the established canon of open source organizational tools because they make the knowledge and tools required to participate immediately available to those who are interested. Experienced open source participants benefit from Mozilla providing these tools because it is what they are accustomed to, and those new to open source benefit because it prepares them for working with other projects in the open source ecosystem.

Comments

Tips for adding comments:

• Include ~~~~ (without "nowiki" tags) as the last text of your comment to include your signature.
• Indent text to reply with a colon :

Examples:

This is is the first comment! Christie Koehler (ckoehler) (talk) 12:53, 7 May 2014 (PDT)

this is the first reply! Christie Koehler (ckoehler) (talk) 12:53, 7 May 2014 (PDT)

Add your comments and suggestions below. Please use this space to comment about this proposal specifically. If you have general comments about the wiki, use this page.

About Developer documentation: A lot of information on how to build and fix things are contained currently in the wiki and not the MDN. I'm faulty of that. Would you recommend that anything which is technically related and/or offer guidance on how to operate in the activity should be pushed to MDN. If yes it would be good to activate Inter wiki links to make it possible to benefit of redirections in between the two entities. For example in Web Compatibility how would we classify Guide and Updating. I'm not sure it will be easy to do. Maybe a different way to go about it is to encourage people to think about it when they create a new page.Karlcow (talk) 15:40, 9 May 2014 (PDT)

Good question. Both of the pages you link to seem fine for the Mozilla Wiki. Web Compatibility is a Mozilla project and those pages document how to contribute to it. As I'm responding to this, I'm realizing that the section distinguishing what content belongs on MDN and what belongs on Mozilla Wiki needs further work. Do others have a good way to describe the delineation between the technical information that should go on MDN vs Mozilla Wiki? Christie Koehler (ckoehler) (talk) 16:52, 9 May 2014 (PDT)

Developer documentation can be confusing to think about because it's both produced and consumed by developers. In short, product documentation goes on MDN; process documentation goes on the wiki. In open source, the source code is part of the product, so things like building and debugging instructions are product documentation. Process documentation includes things like product plans and roadmaps, team meeting notes, bugzilla workflows, etc. Another way to think about it: MDN documents how to interact with code; the wiki documents how to interact with teams. For Karl's examples, I'd say that the Guide is a process doc (people interaction) and the Updating doc is a product doc (code interaction) that would go under the Mozilla Build section on MDN. Jswisher (talk) 10:23, 14 May 2014 (PDT)

About WikiMo: The about page says currently "Governance issues are managed by the WikiMo module, a sub-module of Websites." but it doesn't explain what is WikiMo and the link goes to a table which is not really about Governance. Is there a more appropriate place on the wiki or elsewhere? Karlcow (talk) 15:46, 9 May 2014 (PDT)

David's comments: The only thing that I’d add to the scope is that I think it’d be good to apply a bit of a product/UX lens to the wiki as a community infrastructure, because I believe it will result in more use, more people caring and valuing it, and a general virtuous cycle. Wikis in my experience work if a) the content is well gardened (just like any “content” site), and b) people find authoring & editing to be a fun, pleasant, productive experience (just like any other authoring product). Just because we say it's where stuff “should be” isn’t enough. To that end, I’ll opine that:

• performance of an editing tool is critical to its continued use — it’s true for IDEs, it’s true for word processors, and it’s a place where wikis have traditionally been fairly weak, because of their dawn in the earliest age of CGI, etc. I have the impression that perf on wiki.m.o writes has gone up, and that’s great, and we need to do more to improve perceived perf. As a thought-provoking point: editing an etherpad feels 100x faster to me (even if it’s obviously different).
• we need to encourage, train, and recognize & herald wiki gardeners. (Matt Thompson for example is doing a _stellar_ job of doing that and teaching others how to do that for Webmaker content).

-- Agreed, and already part of our discussions in the Wiki Working Group. Christie Koehler (ckoehler) (talk) 16:39, 9 May 2014 (PDT)

• there’s a lot about wikimedia which feels hasn’t really kept up with our collective expectations around authoring environments. Case sensitivity of pages; wikimedia markup in general, clunky authoring environments, etc. There may be more configuration tweaks & add-ons that we could deploy, I’m not an expert there.

-- Some of this is due to technical debt due to neglect on our end and will get better with time as we bring things more up to date now that we have a dedicate resource working on the wiki. Christie Koehler (ckoehler) (talk) 16:39, 9 May 2014 (PDT)

• the default skin is way better than it used to be and the pages are less painful to my eye anyway than before — we can still do more.

Indeed. We're planning to roll out an updated theme this year, one that is compatible with more recent version of MW.

• having someone act as a product manager for wiki.m.o (and for example care and measure things like daily actives, etc. as a metric of utility of the wiki to the org) would be good — anyone can do that, and I and many others would be happy to coach that person on how to be a product manager with a soul if that coaching was desired.

-- As module owner, I'm also acting as product manager. Happy to have any mentoring you're willing to offer. Christie Koehler (ckoehler) (talk) 16:39, 9 May 2014 (PDT)

• there are people with wiki.m.o superpowers, and we should figure out how to get those superpowers more evenly distributed. [and make it so that some of the things those folks can do don’t require super-anything]

-- Indeed, part of the wiki-gardening too. Christie Koehler (ckoehler) (talk) 16:39, 9 May 2014 (PDT)

• there’s an obvious elephant-in-the-room about wiki.m.o vs. Mana and why we need two. That duality doesn’t bug me too much, but I know it bugs others. Understanding the reason why people use one or the other feels like a good thing to get shared understanding of, even if not everyone will agree w/ the specific decisions.

-- There needs to be two separate wikis because MoCo needs a resource to store privileged information that can't be public. Mediawiki does that very poorly and recommends that people setup a separate wiki if there is truly privileged information that needs to be separate. We might be able to achieve the same thing if we switched to a confluence-only setup, but that would remove ownership from the Mozilla community, to which I think there are huge downsides. Christie Koehler (ckoehler) (talk) 16:39, 9 May 2014 (PDT)

DavidA (talk) 16:10, 9 May 2014 (PDT)

This is good feedback but not related to the about page. I think Christine wanted feedback about the About page Karlcow (talk) 16:12, 9 May 2014 (PDT)

This is true. I've answered DavidA's comments inline. If there aren't any objections, I'll move his comments and the associated responses to this Sandbox we have for collecting feedback. Christie Koehler (ckoehler) (talk) 16:39, 9 May 2014 (PDT)

DavidB's comments: Just one thing that occurred to me was around possibly needing to add an additional part to the section of who owns different parts of the wiki. There are some pages, like the main page, where the content isn't open for anyone to edit. I'm not entirely sure who can edit the main page or how I could become one of those people if I wanted to. It might be worth having a 'protected content' item to call that out.

Noted. I'll add something about protected pages. We don't yet have documentation on the process for becoming a user with administrative rights, nor have we audited our current user lists to see if they still make sense. Would you be okay moving forward with this policy while we are still figuring that out? Once we do, we can update it with a link to the appropriate information. Christie Koehler (ckoehler) (talk) 16:26, 9 May 2014 (PDT)

Gerv's comments: Firstly, thanks for taking this on. The wiki is a vital resource and it's great to see it getting love. Comments on this page:

The word "comprehensive" is in the purpose. That would suggest that the wiki needs to contain information about everything. The use of the term "encyclopaedia" also suggests this. I think that's actually an anti-goal, and I suspect you do too - we have better places for some info, like SUMO or MDN. It also seems to suggest that if the wiki is missing information on some topic, there is an obligation on someone to provide that information, to achieve comprehensiveness. I'm not sure that's true either.

An alternate take: I would define the purpose of the Mozilla wiki as: "A low-barrier-to-entry place for Mozillians to choose to store dynamic but long-term-relevant information about Mozilla products, initiatives and sub-projects."

"Dynamic" is its distinctive over www.mozilla.org. "long-term-relevant" is its distinctive over IRC or Etherpad. The wiki fits into an important niche between the permanance of one and the real-time collaborativeness of the other.

Gerv (talk) 05:51, 13 May 2014 (PDT)

-- I think Gerv's distinction is really spot on: dynamic(wikimo) vs static (mdn) but both long-term-relevant. This is very important because the line between documentation in general and documentation for (new) contributors for a specific team is really thin, IMO. So the criteria dynamic and long-term-relevant seem a good way to guide the user in deciding. (The two cents of a new contributor who fought a bit to navigate the mare magnum of mozilla's documentation on contributing :))

Madamezou (talk) 09:05, 18 May 2014 (PDT)

Joelle's comments: Does the About page need to be written in a specific tone or language? As a new contributor to WikiMo, the Purpose and How is the Wiki… statements still seem a bit opaque and removed. I wonder if we can incorporate the language used in Wiki Working Group meetings into this About. Last Wiki Working Group meeting the wiki was described as "the innards" of an organization. That term clarified a few questions I had about the scope of WikiMo. It implies what is already stated on the About page in a more inviting way: that the Wiki is a publicly available internal platform; that it makes public information neither designed nor intended for end-users. While I understand that "innards" might not connote the same meaning for some readers, can we consider a tone that is more inviting, yet pithy? Jo as Queeniebee (talk) 17:02, 13 May 2014 (PDT)

Tristan's comments:Very happy to see some effort put into the Wiki! I agree with its central role as a tool for participation and memory of the project along with Bugzilla. Nothing to add at this point but will do if anything comes up. Keep up the good work! Tnitot (talk) 02:58, 14 May 2014 (PDT)

Mitchell's comments: I echo the appreciation for taking on these topics. I have a couple of questions. First, I wonder if the two purposes are complementary or at odds with each other. One is to the encyclopedia reference, the other is to facilitate interaction. I can imagine both working well if there is very clear separation and wiki-care. There's probably some development of good practices and some sustaining grass-roots encouragement of a good separation of these two activities as well. You may well already have thoughts about this, so I'll stop here.

Secondly, it would also help me to get a clear picture of how the wiki relates to other workflows and results. Right now teams use a whole variety of tools to collaborate. I'll give a few examples here. The goal isn't to be picky; it's to give an idea of the kinds of questions I can see developing. If a team uses etherpads or google docs for example, how do we think about the relationship of that output to the wiki? If we have an official blog post, how does that relate to the wiki? A very specific example -- we just made statements about DRM and our products in the Mozilla blog. Would someone add something to wikiMO to point to that content? or copy it in the wiki? or is that kind of content outside the scope?

And on a related note, are you thinking people will maintain wikiMO as a resource, or more of asking Mozillians to use the wiki as a workplace to create the encyclopedia?

<>mitchell@mozilla.org (talk) 22:43, 20 May 2014 (PDT)</>