Re: Proposal to manage documentation similar to (or along with) core software.

I think it would be helpful to have a more clearly managed approach with 
someone in charge - Israel would be great, if he were prepared to take 
up the challenge. It would be good also to have a more structured, 
organized approach to sprinting on documentation too, so perhaps we 
could entice some more people in to the process, by setting out some 
more clearly defined tasks (rather like the trac tickets, but perhaps 
with more detail and guidance)*.

I drafted a kind of 'vision' for core docs once - here's the link (I'm 
running for cover):

http://docs.google.com/View?id=dfrk42sj_102c3xzjxdn

I'm more than aware that we need a documentation 'process' that we can 
all join in to. I'm anxious because my day job is too demanding at the 
moment and I can't spare the time to do much documentation, but there's 
no one to pick up the reins.

Anne


* for instance I was able to get a group of colleagues to help with 
screen-shots for the user manual, by giving them access to a Plone 4 
instance (rather than asking them to install Plone 4 themselves)


On 14/04/2010 03:03, Alex Clark wrote:
> Hi all,
>
> I'm sure this has come up before but I'm wondering if it could gain some traction now.
> I've been lurking in #plone-framework and I really love the proces, and daily grind
> of work and activity that goes on in there. I'm wondering if we could inject some of
> that enthusiasm and activity into the documentation project.
>
> We have soooooooooo much good documentation out there, but very little structure
> or organization AFAICT (and not due to lack of effort, I know people have
> been working hard at various levels).
>
> To that end, I propose we focus on the following:
>
> 0. Elect a "doc team leader" similar to the FWT leader, and have
>     the Plone Foundation pay a small amount to them to encourage
>     them to do a good job. It could even be the FWT leader, but
>     I doubt Eric or Hanno want the additional responsibility.
>     I nominate dukebody :-).
>
> 0.5. Elect a "doc team", again mirroring the FWT process here.
>
> 1. Identify all the resources we care about, e.g.:
>
>      - FAQs
>      - Manuals
>          - Plone Core Developer Reference
>          - Developer Manual
>          - Plone 2.5 User Manual
>          - Plone 3 User Manual
>          - Plone 4 User Manual
>          - Plone Upgrade Guide
>          - Add-on Products Developer Manual
>          - Plone Theme Reference
>          - PAS reference manual
>          - Fix for CMFEditions
>          - Zope Component Architecture Manual
>          - GenericSetup
>      - Error References
>      - Links
>      - Glossary
>      - Books
>      - Demonstration Movies
>      - Knowledge Base
>
> 2. Identify a subset to version and release.
>
> 3. Work toward a release. Ideally one that corresponds to a
>     software release, but I suppose that is not mandatory.
>
> 4. Have fun and profit.
>
> 5. Hang in #plone-docs 24/7.
>
> Thoughts?
>
> Alex
>
>

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

_______________________________________________
Plone-docs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plone-docs

begin:vcard
fn:Anne Bowtell
n:Bowtell;Anne
email;internet:[email protected]
tel;work:+44 (0)1865 882829
x-mozilla-html:FALSE
version:2.1
end:vcard