[drupal-docs] Handbook v2

[Boris Mann]

On 19-Mar-05, at 7:30 PM, Anisa wrote:

> I added some details under each of Boris's root book headings, just 
> looking at the original handbook.  I apologize if that was a little 
> counter productive.  ^.^;

No problem -- your help/thoughts are much appreciated. Made me go look 
and refactor again: http://dev.bryght.com/t/wiki/HandbookVersionTwo

> I also added a translator guide.  Not sure on the doc writer's guide.  
> Not worthy of it's own book, perhaps.

Translator is also likely not it's own book, but a sub-section of 
Working Groups. Although, if we want to make per-book stuff trackable 
(and permissions and so on), then more root books is actually better. I 
see some activity over in organic group land, so who knows :P


> I don't know how permissions work right now, so perhaps a description 
> of that would bring to light deficiencies and benefits in the current 
> system.

Basically, to fully be able to edit all book pages, Site Maintainers 
have fairly complete powers over both comment and node editing, 
deletion, and promotion. Essentially, too much power to open it up to 
everyone.

We need a permission to be able to edit all book pages.

> Perhaps it's helpful to think of it in terms of workflow.  I do think 
> it's important that new documentation bits go through the 
> documentation team so that they can ensure the quality of the 
> documentation.

Actually, I would reword this to say that new documentation gets to the 
attention of the people who care about those bits.

The permission and workflow question means we should probably do a wiki 
page on workflow and suggestions....I've run out of steam for now.

> Forum threads certainly should not go straight to the handbook.

Yes, absolutely. This is where knowledge gardening comes in: take 
lessons learned and write up a book page.

> I wonder if (very theoretical, no clue how this all works) it might be 
> helpful to have it like a bug/issue list.  People can submist an issue 
> they have with the documentation, and the docs ml will get a weekly 
> summary of all the open issues.

In the case of documentation, I think this process is too strict. 
Refactoring towards better documentation is good, but I think that only 
issues would discourage involvement in comments/improving docs.

But, we do have a documentation component to file issues against now. 
Doh! I meant to actually start using that for to-dos a.k.a. tasks. So, 
documentation team can identify issues (and users as well) and people 
can assign tasks to themselves if they are going to take care of it.

--
Boris Mann
http://www.bryght.com