Re: Proposal to manage documentation similar to (or along with) core software.
Alex Clark <[email protected]>
| Newsgroups | gmane.comp.web.zope.plone.documentation |
|---|---|
| Organization | ACLARK.NET, LLC |
| Message-ID | <[email protected]> |
On 2010-04-14, Israel Saeta Pérez <[email protected]> wrote: > I don't really know how to fight against the lack of motivation among > the people working on documentation, including me. Do you like getting paid? That is what I am proposing. I don't know the likelyhood that the PF will buy into this, but it would seed a lot of activity I think. > I like to think that > lowering the contribution barrier with the division > manuals/knowledgebase will help, but with the UI work and the > policies/permissions/licenses work apparently stalled, I don't know if > we will manage to see the benefits of the knoweldgebase soon. Me neither, and I hate stalls. Find a way to work around it, would be my suggestion. > I've already been working on the Plone 4 documentation for some time, so > I guess I wouldn't be a bad "leader" for this release. Are we talking > about 4.0 only, or 4.x? 4.x >> 0.5. Elect a "doc team", again mirroring the FWT process here. > > http://plone.org/documentation/kb/documentation-team-editors is the > current list of "doc team editors", and > http://plone.org/documentation/kb/plone-org-documentation-editors-roles-and-responsibilities > their responsabilities as stablished two years ago. This reads a bit dated to me, and in fact it says "This scheme will be replaced in a close future by manual owners. ". How about this: With each release, the new doc team leader and members decide their roles, and accounce them to the community. *shrug* I don't know much about how this works within the FWT, just that everyone owns something and collectively, eventually, their work forms a release. > We care about everything and have a quite long list of more-or-less > defined tasks at https://dev.plone.org/plone/report/8 . The most important thing I can think of is end-user documentation, followed by "integrator" documentation. Developers, at least for now can figure it out themselves ;-) (Well, not really but just trying to prioritize). Maybe installation docs, too. > finished. I cannot say "oh yeah, I've sucessfully documented portlets", > because there will always be use-cases and functions not explained. Some > parts of Plone are almost completely undocumented (e.g. some Plone 3 > PLIP-based features). I don't really know how to identify a subset of > tasks and release if it isn't corresponding to a software release. Work towards a release. :-) There is only so much to be said about portlets in a Plone 4 end user manual. The marketing peeps already cover "What's new?" AFAIK. >> 4. Have fun and profit. >> >> 5. Hang in #plone-docs 24/7. > > This is the easy part. :) > > -- israel > > > ------------------------------------------------------------------------------ > 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 -- Alex Clark · http://aclark.net Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin ------------------------------------------------------------------------------ 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