User:Ckoehler/About wiki.mozilla.org
| date created | 2014-05-09 |
| comments deadline | 2014-05-26 14:00 UTC |
| contributors | Christie Koehler, Lyre Calliope, Gordon Hemsley, Justin Crawford, Larissa Shapiro, Jennie Rose Halperin, Mark A. Hershberger, and Jason Crowe. |
| status | draft |
| To make comments: | Edit this page, putting your comments in the #Comments section. Include ~~~~ without the "nowiki" tags to include your signature. |
| Preamble: The Wiki Working Group has formed to kick-start a revitalization of the wiki and to create a framework for empowering the entire Mozilla community to participate in and sustain this revitalization effort. A first step in this revitalization effort is this About page, which seeks to clarify the purpose, scope and governance of the Mozilla Wiki. Once adopted, this text will reside at About and serve as our guide for interacting and making decisions about wiki.mozilla.org.
We are actively seeking comments from our community until 26 May 2014. Those comments will be considered and incorporated and this page adopted into the wiki by 15 June 2014. In review this document, please consider the following questions as you review and make your comments:
|
Purpose
This wiki (wiki.mozilla.org, AKA MozillaWiki or WikiMO) is the official public wiki of the Mozilla Project. It is the encyclopedia of the project and is intended to contain comprehensive and dynamic information about Mozilla products, initiatives and sub-projects.
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.
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.
What content is appropriate for the Wiki?
- Any content pertaining to Mozilla's products, initiatives and sub-projects that is not end-user documentation or developer documentation.
- Any content pertaining to Mozilla's mission, strategy or history.
- Any content that supports Mozilla's mission or community.
- Any content that is related to the on-going planning, coordination or other contribution activities of Mozilla projects.
- 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.
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 documentation is written for programmers developing for Mozilla products like Firefox as well as the Open Web. This type of content includes technical reference information for programming languages and platforms and is most suited for MDN.
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.
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 here:
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)
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).
- 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.
- 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.
- 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.
- 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]
- 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.