As we have a wiki at hand it might be a perfect place to organize contributions: http://www.boltwire.com/index.php?p=docs.contribute
I quickly put together some Documentation Guidelines: http://www.boltwire.com/index.php?p=docs.contribute.guidelines Feedback to both pages is welcome. I don't think it's hard to organize our efforts currently because there is only a small number of people likely to contribute: Dan (as Lino said: never let a developer create documentation) Linly Martin Kevin Hans DrunkenMonk blues Markus Sorry to anyone I forgot. How to know what is to be done? I would add a data field to all pages "unvisited". If anyone is working on a page and made changes, the status is set to "edited". If it's finished, let other users check and if everybody is happy remove the status. This allows: * to see abandoned pages that can be deleted in the future * to see which pages are to be reviewed Markus On Wed, Mar 24, 2010 at 12:05 PM, Martin <[email protected]> wrote: > There is a community project working - it is Wikipedia. > Their secret seems to be that some people are eager to supervise what > users are typing in. > > To get the same here we could split up documentation work in chapters > and assign some core users who are interested in BW to take care of > their part of the docs. > > Call them maintainers. > > We can have an internal community to keep track all of the efforts, > doing doc reviews and build up some pressure. > We would need a wikipedia like strict structure to make the docs > consistent. > > I would take care of forms because I need them all the time. > > Greetings, Martin > > On Mar 24, 9:46 am, Lino <[email protected]> wrote: >> I took a deeper look at docs and here's what I noticed: >> 1. Documentation problem exists in almost all community projects for >> simple reason that there is no idea how to fix it <> in commercial >> projects it is clear and simple WHO does WHAT, WHEN and HOW. BW docs >> clearly shows it's community nature :) >> >> 2. It is not just an documentation problem. It's origin is in rapid >> development. If you change things all the time, WHY is coming up. >> >> 3. Insufficient documentation causes small community, which means that >> you don't have folk resource needed for documentation building... >> >> So, just making good documentation is simply not enough. You have to >> freeze the project at some stable point, make most (if not all) >> plugins running good enough and document it for both, devs and users. >> But primary for users (they don't read code :) >> >> There is one more thing: user manuals should be written by users, not >> devs. If developer writes it, one should downclock his brains to 3% >> and explain to him self how to do do what he is up to. >> >> Finally, I suggest to make rock stable 3.5; pass/check/update all the >> plugins, document it and fix as Lite version. During the time, it will >> grasp some users, get totally debugged, collect documentation... >> >> 4.0 is a different story - but it is easy way if you have good >> structured and correct documentation as a blueprint for the new one. >> >> Dan? Guys? > > -- > You received this message because you are subscribed to the Google Groups > "BoltWire" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/boltwire?hl=en. > > -- You received this message because you are subscribed to the Google Groups "BoltWire" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/boltwire?hl=en.
