Editor Workflow

to replace current publish workflow currently used on plone.org

Purpose: to establish quality control before new documents are published.

Time Frame: Editors should do this as frequently as possible so there is no bottle neck created. Edit as each new document comes in or on a daily or weekly basis.

1. An automatic notification gets sent to the editor's mailing list saying that a new doc has been created, in X section and is titled Y. 
2. The editor for that section verifies that the new doc is in the correct section.
3. The section editor copy edits and fact checks the doc. 
4. The section editor sends comments/changes to author.
5. The author makes appropriate changes and then submits for review.
6. The section editor publishes the document.
   

Ongoing Clean Up Activities

These duties are to be performed on an as needed basis. Good things to do with your extra time or during a sprint. All of these things need to be done on a regular basis but aren't as time sensitive as publishing new documents.

• Identify missing documentation and file on trac.
• Identify people who can finish unfinished/needed documentation.

• Mark old 2.1 and 2.5 documentation as obsolete, where appropriate. The documentation for 3.0 would be the only documentation surfaced explicitly in the documentation view, but 2.1 and 2.5 documentation would still be accessible via search (see also the designs for the theming UI where we could add tags for 2.1, 2.5, etc.) Alternately, sort 3.0 docs to the top, then alphabetically by topic.

• Flag documentation as related. Specifically thinking of the crossover between theming area and buildout / Zope3 technologies.
• Update/edit keywords.
• Coach and mentor authors.
  
• 
  

Suggested needs:

• Utilize the "call out" style to identify where things have changed (ie., in Plone.2.5, we did this; in Plone 3.0.x, we now do this. Point to related documentation where appropriate.
• Document recipes (separate out buildout recipes from paster recipes). For now, document as individual pages, possibly automate in the future.
• Remember to tag documentation as "start here". Determine what qualifies as "start here" documentation. May need to grep for docs produced since 3.0 was released to make sure they get reviewed properly. Be judicious about what items are start here docs, as these will be surfaced on the home page for the docs section.
  
• Write overview documentation for key areas (theming, buildout). This would point out prerequisites, core tips and tricks, next steps, dependencies. 
• Possibly provide a view into the "start here" documentation, sorted by topic.
• Discuss "moron's guide" and increased granularity of documentation.
• Consider branding an "overview" doc for each section. Not the same as "start here," it's more of an "uber-start-here".
• We need to think long and hard about what's more important: seeing docs by version # or docs by "start here" or docs by section
• Do we want to alter any of the names of the docs to have version #s in them to reduce confusion?