[Plone-docs] Looking for substitute

[Christian S. <chr...@da...>]

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