[documentation] SUMMARY for Proposal to open up editing rights

[Larry Garfield]

On Tuesday 09 September 2008 5:26:53 pm Addison Berry wrote:
> I wanted to summarize the discussion around the proposal to open
> editing rights to all authenticated users. There were a lot of ideas
> that came up (and not all are in this summary because they may have
> veered off the target topic. Don't fear they are still being compiled,
> just not on this topic. :-))
>
> So, the proposal as originally put forth:

> Related (in a hook_form_alter kind of way): Making revision logs
> required. Again, we should be able to add a simple validation rule to
> the drupalorg.module. We just need someone with a little bit of time
> to make a patch.

Even if we don't end up opening edit rights more widely, this is a good thing.  
I keep forgetting to fill in revision info even when I should do so, so 
having the system poke me about it would be appreciated. :-)


> Regardless of "speed bumps" or not, we also touched upon the notion
> (also in the original proposal) that there will be restricted access
> to certain sections of the handbooks. The getting started guide is a
> primary target for this, although the Them guide was also raised as a
> candidate. I think this topic bears a touch of thought to have a clear
> list of "restricted areas" before we open editing.

I'd mentally divide the handbooks into 3 general conceptual areas:

1) A person's first few days in Drupal.

2) Reference material for specific systems or modules.  (Views API, D6 Menu 
API, D6 theming guide, etc.)

3) Other.

#1 I'd say should be restricted.  The "first impression" is something we want 
to be very careful with, and I have no doubt the language there will be 
heavily influenced by the redesign process.  That should not be opened 
globally.

#3 is, I think, the easy "yes" for opening up globally, if anything is.  
That's the wiki-esque parts of the handbook, where wide-edit ability makes 
sense.

#2 is up for debate.  Ideally, those docs would be written by the people who 
wrote that API and actively maintained by them, so we don't want just anyone 
adding incorrect information.  In practice, we know that doesn't always 
happen so we may or may not want to allow anyone to tweak the menu API docs, 
for instance.  Perhaps those can either have a dedicated "owner" or be 
public, case-by-case?  (Eg, we have a "maintainer" for the theming API docs 
so that's not open, but menu isn't be actively watched by chx and pwolanin so 
that's open to all, as a possible example.)

-- 
Larry Garfield
larry at garfieldtech.com