Hey all,
I'm afraid I will have to retire from the doc team and would like to
find someone who will be responsible for this task:
> - Produce "trails" of documentation -
>
> :: Requires: 1 volunteer to document and promote the "trails" mechanism,
> 1 volunteer to choose and structure a pilot "trail", and possibly others
> to contribute to the trail.
>
> This is by far the best idea we've had, and the most concrete task. To
> summarise, instead of aiming for perfection across all documentation, we
> should pick up a few key topics that we reckon most members of a
> particular audience would need to know. Examples may be "Connecting to
> LDAP and other user sources" or "Developing new content types". This
> "front-line" documentation should be thought through in more depth than
> the rest of the how-tos and short tutorials.
>
> The idea is that people have a small number of places to start from, and
> can then search for more specific documentation (over which we exercise
> less tight control) once they have solid fundamentals. This makes a
> manageable task out of an enormous one. It is not quite as good as
> starting from scratch and producing a "Plone book", but it can be more
> than good enough for audiences who just want some authoritative
> information, and are willing to connect some of the dots themselves.
>
> I propose that we start with a single trail as a pilot. Whoever
> volunteers for this gets to pick. A trail should be a Reference Manual
> (we'll use the sections and audiences to ensure they end up on top,
> possibly also a Smart Folder or template to show them more prominently).
>
> The first step in defining a new trail is to work out the best learning
> path for the intended audience and assess this against existing
> documentation. From this, a workable structure of sections and
> placeholder pages should be created. Some kind of gap analysis needs to
> be completed to find out how the documentation we've got already matches
> what we want. Then, one of four things may happen:
>
> (1) We link to existing how-tos and tutorials from a particular page in
> the trail. There will probably be a short intro with context to save
> users from having to browse through documentation that happens not to be
> relevant to them.
>
> (2) We find existing documentation that's close, but not quite good
> enough. We fix it up, possibly asking for help from the original authors
> or experts in the community, and apply some pressure to make it happen
> quickly.
>
> (3) We solicit new documentation, either by writing it ourselves or
> asking something else nicely. Again, we prioritise this work and try to
> reward people for producing something in days and weeks rather than months.
>
> (4) We leave that part of the trail blank. We can publish a trail that's
> not yet fully complete if some nice-to-have sections are missing but
> it's otherwise useful. Having clearly defined holes to fill help get
> things completed.
>
> I'll stop there. I'm explicitly leaving out specific such as "deal with
> Plone 3", because ideally it should be a consequence of the processes we
> come up with.
I opted for doing that one but can't now, so anyone interested post here!
Cheers
Christian
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
Plone-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs
