THIS PAGE IS A WORKING DRAFT
	The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page.

This page summarizes discussions and ideas regarding contributions to Thunderbird documentation.

Overview and Goals

MoMo has a major goal of expanding the community of contributors and volume of contributions. Documentation is one way people can contribute.

There are three general "categories" of TB documentation:

• MDN (documentation for extension writers)
• Knowledge Base (documentation for end users)
• Third-party (documentation that people write and publish on non-Mozilla properties)

Categories

MDN

The Mozilla Developer Network hosts developer documentation for Mozilla products including Thunderbird. (The documentation area of the site was formerly called the Mozilla Developer Center (MDC).) Previously, the focus of the documentation effort on MDN has been to help add-on developers rather than provide core documentation, as experienced TB developers are satisfied with the source documentation (which they access through mxr).

The MDN documentation infrastructure is adequate and not very difficult to use. It is not a barrier to contributions.

Questions

• What problem are we trying to solve? Are we trying to expand our extension contributions? Is lack of documentation an impediment, or is API instability the bigger problem, or what?
  
• Developer documentation (as opposed to end-user documentation) tends to require a bigger effort from staff, particularly senior developement staff whose free time is limited. If it would take an effort of 8 RDMs (Random Documentation Units) to end up with a useful doc set but we can only expend 2 RDMs, is it worth doing 2?
  
• Where are people looking for documentation? MDC? MozillaZine? stackoverflow?
  
• What are people looking for? API reference? How-tos? Tutorial / getting started guides?
  

Actions

• Informal poll with recent add-on developers
  
• Intern (if we could define the goal and the task, there might be budget)
  
• Question / answer bot on maildev, where conversations could be flagged as relevant for documentation
• Capturing question / answer exchanges on tb-dev list
  
• More rigor around flagging bugs with dev-docs-required keyword
  

Knowledge Base

The Thunderbird Knowledge Base site works in conjunction with the Get Satisfaction support site. We have a process where we review topics on Get Satisfaction, create bugs for problems that are of general interest and create corresponding Knowledge Base articles.

While the Knowledge Base site is the most likely area for contributions, the platform is flaky and difficult to use. Most casual users would not be able to use it without training and support.

Questions

Actions

• Get sumomo ported to Mozilla's new Kitsune platform (Q1 2011)
  • Get the site's comment moderation / feedback mechanism fixed so that people can more easily incorporate their fixes into the KB articles directly instead of adding to the out-of-control comment cruft.
    
  • Encourage people who write good responses to GS issues to create their own KB articles.
    

Third-party

More than other types of contributions, documentation contributions are dispersed (that is, not necessarily published or posted on Mozilla properties, and often without any knowledge or involvement of MoMo folks). Some of these third-party contributions include:

• MozillaZine
  
• Thunderbird FLOSS Manual
  
• ...
  

We need a "gardener" mindset rather than an "owner" mindset. We need to encourage these contributors and make sure their work is linked up to each other and to the properties we "own" (MDN and the Knowledge Base).

Roland is in touch with the MozillaZine community and is fostering that relationship. Jen is in touch with the FLOSS Manuals community and is fostering that relationship.

Questions

• Does TB have much presence on stackoverflow? should we be involved there?
  

Actions

• Investigate stackoverflow and see how we could contribute.
  
• Establish a routine for searching for third-party documentation contributions; make contact