[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