[documentation] Proposal to open up editing rights

Addison Berry drupal at rocktreesky.com
Fri Aug 29 09:31:47 UTC 2008


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)



More information about the documentation mailing list