User:Sj/essays/editing barriers

Barriers to editing

Reduce barriers to editing, increase barriers to vandalism

Reduce barriers to editing. Add WYSIWYG options, add one-click comemnts/feedback, make section-editing more obvious and more friendly. Reduce the number of warning messages, many of which scare people away. Reduce the average time to edit from ~1 minute to ~15 seconds.

Increase barriers to vandalism. Add speed-bumps for external URLs, for new content from unknown users with vandal-beloved keywords, add delays between content addition and publication to anonymous readers (99% of readers], add delays-until-verified for users who don't meet a very-low trust bar [no edit history, no edit summary, unknown/historically troublesome IP block, &c]. But don't block any of these users from saving their edits and having them seen by themselves when they revisit the page and by other editors. Make this review process transparent to all.

Protection is a hack

Protection is a hack. When it was first implemented in early 2003, it was noted as such; from the start, there has been the idea of improving on protection by "reduc[ing] the requirements for sysop intervention for useful things to happen". http://en.wikipedia.org/w/index.php?title=Wikipedia:List_of_protected_pages&oldid=787186

Wikis are designed to be editable; the ideal wiki is as open to incoming content as possible -- a metric of a wikis success at wiki-nature might be how long it takes first-time contributors to make typical edits, and how long it takes them to get/see feedback.

"Open to incoming content" isn't the same as "open to changes in what everyone else sees as outgoing content". We should strive to increase our openness to inboud content, even as we tighten quality controls on outbound content. Articles for Creation is an even worse hack than protection, and regularly fails silently and completely [the user never comes back, or thinks their work is lost; their work *is* lost].

Semi-protection is also a hack. One way to make these protection hacks work more effectively is to recognize that they are *not* the desired solution, but a quick way to implement something close. Protection is a 'reasonable' hack because anyone can still edit the talk page, leave comments for page-contributors on *their* talk pages, &c. New editors don't know any of this. Old editors and vandals don't need to be told what protection's all about.

Suggestions for improving these hacks through more information :

• make protection templates very short and inobtrusive; not in the header, to maintain a clean interface : most readers don't need to know about them (an NPOV or Disputed template can be placed there if needed, that's separate. If an article's being protected just b/c it was on slashdot, that's different).
• keep the "edit" button for protected pages. add a little icon in that tab if needed, to denote the protected nature. Offer a message on editing, varying by protection type, explaining briefly why the protection, and where to post edits and suggestions (the talk page), with a link to a longer explanation of who can edit where, how to request unprotection, how to ask for help, &c.
• update the "this page is protected from editing" message one gets when viewing the source of a protected page. make it friendlier, again linking to where one *can* suggest changes and explaining this in postive rather than negative terms.
• make it more clear than it is now who applied protection when, and what their protection-summary was. pull this information into the notices listed above.