[documentation] SUMMARY for Proposal to open up editing rights

Tue Sep 9 22:26:53 UTC 2008

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:

Open up general handbook page editing to authenticated users for a trial
period of one month. Publicize what the deal is, and then assess the
number of reversions needed, and decide if we will continue or close
back up. We can extend the test a month at a time until we are sure of
our decision and just keep communicating with the community about what
the progress is.

There were two overall sentiments in reaction to the proposal. If I  
can be broad for a moment, we basically had one reaction of "Yes,  
let's give it a whirl." and a second reaction of "Maybe, if we can  
"control" it somewhat."

I got the overall feeling that those who responded were generally in  
favor of exploring it, though with some with hesitation. Here are some  
ideas that were put forth in terms of people's reservations/ways to  
make it a more successful run:

"a mechanism to keep an eye on the diffs"
We do have the Recent updates page at http://drupal.org/handbook/ 
updates and thanks to Moshe there is a patch to add a direct link to a  
page's diff from that table (http://drupal.org/node/304667).

"adding some verbiage about the style guide and anything else that  
would be helpful in the node form for book pages"
We can definitely add something using hook_form_alter or a theme  
override. We would need to provide the patch for infra to apply, so  
anyone willing to pop up and take that on, would be appreciated.

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.

There was also a feeling from quite a few of wanting to have some sort  
of "speed bumps" built in to the process. One suggestion was to have  
even more restrictive access to the current doc team rights. Though I  
got the feeling most did not agree with that direction. Some  
suggestions put forth for regular authenticated users being  
"moderated" or otherwise not directly given access were:
- revision moderation where edits could be made but the edits needed  
to be approved by the doc team before going "live"
- "assigning each doc team member a manageable number of random
handbook pages to "adopt for life" and monitor for spam/vandalism."  
the "owner (or owners?) would then be notified when chnages are made  
to their pages.
- a "time delay" for new accounts. So that new auth users would have  
to wait a certain period prior to gaining creat/edit rights.
We could also institute a rating/flagging system on the pages.  
Something like:
- "This is so good we're calling it 'Official' and locking it."
- "This has been through loads of edits, vote to make it 'Official.'"
- "Brand new page, edit me and make me better."

Another suggestion for fast-tracking certain users, if speed bumps are  
in place, is to "automatically add module authors to the documentation  
permissions."

There are a lot of ideas here and the thing is we need to decide is if  
instituting these restrictions is necessary in order to proceed. It  
isn't just a matter of how we feel about open access, but all of these  
"more restrictive" suggestions/enhancements will require signicificant  
coding and working with infrastructure to get them into place. that  
is, it won't happen any time soon and definitely won't happen with  
some real elbow grease. These go well beyond a few lines of  
hook_form_alter. The current infrastructure is not set up to do these  
kinds of things. I'm not saying they can't happen ever, but simply  
that they can't happen now and we would need to dedicate ourselves to  
underlying grunt work to get any of these systems in place.

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.

So, with all of that here is what I see as the next steps:
1) I think any way we go that the two modifications to the node edit  
form suggested should be implemented. These two can be opened as  
issues on the infra queue and patches need to be rolled:
--- Make revision logs mandatory.
--- Add additional "help text" on the book node add/edit screen.

2) We should also identify which areas of the handbook will be  
considered "restricted" (e.g. the Getting started guide)

3) Decide if we wish to proceed without "speed bumps" for the one  
month trial period or wait until we determine which to pursue AND get  
them implemented on d.o.

My personal feeling is that we give it a try for the trial period and  
if things seem too chaotic, close it up and then pursue the more  
restrictive options. We can leave item #3 open for discussion the rest  
of this week and make a final decision on Sunday, Sept. 14. Feel free  
to argue back and forth all you want but also please give your clear  
vote for or against the original proposal as it stands (open editing  
to all auth users) before Sunday. We will tally responses from the  
mail list and those present at the IRC meeting on Sunday for a final  
decision by the team.

- Addi (add1sun)

On Aug 29, 2008, at 5:31 AM, Addison Berry wrote:

> I'll start by apologizing for the long email here but I think this
> deserves more than a few sentences. Also note that at the end I've got
> a deadline for responses of Sept. 8. ;-)
>
> So I have a proposal to put out to the team regarding opening up
> editing rights to all authenticated users on d.o. This would be a big
> change and I'd like us to really hammer this out in discussion so that
> we identify and address pitfalls ahead of time as well as possible. I
> have long been a proponent of absolutely *not* opening this up and I
> still have concerns about it, but I'd like to see what the community
> would really do with it. The Drupal community is very different now
> than it was several years ago, whether it is different in a way that
> would make open editing successful this time remains a question.
>
> Before I get to it, a bit of history:
> This has been done in the past and failed. Years ago all auth users
> were allowed to edit the handbook and there was too much vandalism and
> spam to be caught and cleaned up by the community. This is still a
> concern and not one to be taken lightly.
>
> But there are some definite points to be looked at:
> * It requires MUCH less knowledge and time to fix a typo than it does
> to author a new page. Same with rolling in comments, another common
> task that the docs team is stretched a bit thin on.
> * New users are the best poised to ferret out errors in documentation,
> but also the least likely to create new pages.
> * While the barrier to joining the documentation team is low, it is a
> barrier nonetheless, and one that is non-obvious to new users, whose
> input we need the most. I've also found that many new people just
> won't take the step to ask because they feel that it means they have a
> certain time obligation that they don't feel they can "commit" to.
>
> Some issues we will need to look at:
> * We have a mix of input formats out there and anything above Filtered
> HTML needs to be restricted for security reasons. So even if we open
> it up there will definitely be many pages that folks can't edit unless
> they join the team, particularly pages with images. We can explain
> this and make it clear what is going on but there will still be a lot
> of folks that don't read wherever we happen to explain it and will
> complain a lot. So we need to be ready for lots of forum posts/issues/
> irc pings about this unless someone has any other brilliant ideas
> about it. ;-) We should have a standard explanation written up that we
> can point people to and/or copy/paste into emails, etc.
> * We are going to get vandalism, no doubt. So the trick is to see if
> the community can actually self-maintain fairly well and keep up with
> it. The doc team in particular will need to make an extra effort to
> keep an eye on things and be as responsive as possible about reverting
> things and helping clean it up. this is the kicker and if this doesn't
> happen, then this fail. Any and all ideas about ways to help us track
> what is happen and deal with it quickly are welcome. One thing that
> comes to mind is that we do have a Recent updates page (http://drupal.org/handbook/updates
> ) and it would reduce a click if the table included a link directly to
> the revisions tab of the page in question so you could easily review
> the list, see the revision history and get a quick diff on changes.
> This would require a patch to the d.o module so I'll write up a patch
> for that either Sunday or next week.
> * Any other issues we are missing here?
>
> The idea is to try this out as a test. Here is my general plan. Help
> me shore it up:
> Open up general handbook page editing to authenticated users (since
> they can only edit Filtered HTML nodes, the Getting Started Guide and
> other more "official" resources would be off-limits) for a trial
> period of one month. Publicize what the deal is, and then assess the
> number of reversions needed, and decide if we will continue or close
> back up. We can extend the test a month at a time until we are sure of
> our decision and just keep communicating with the community about what
> the progress is. Basically, the community has asked for this and I
> want to see if we can really handle it. If it works, awesome, if it
> doesn't then this will give us some recent experience and data to
> consider when the request is raised again.
>
> So, let's talk about this on the mail list for a week or so and get
> ourselves aligned about whether to agree to the proposal or not and
> also hash out idea for how to actually deal with it. Please respond
> with your thoughts to this list by September 8.
>
> Thanks
> - Addi (add1sun)
>
> --
> Pending work: http://drupal.org/project/issues/documentation/
> List archives: http://lists.drupal.org/pipermail/documentation/