[documentation] Proposal to open up editing rights

[Joshua Brauer]

It's certainly worth giving it a try.

While editing the d.o module it might be good to look at adding some  
verbiage about the style guide and anything else that would be helpful  
in the node form for book pages. Whether or not the editing remains  
open this would be handy for people creating new pages as well as  
handy links for anyone editing the form. Perhaps even a handbook  
editing pseudo block on the form (providing a little CSS can be added  
to make it look sharp).

Josh


On Aug 29, 2008, at 3: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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1592 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/documentation/attachments/20080829/68e5dd53/attachment.bin