User:75.57.242.120/Pending changes questionnaire

Welcome to the review/recommend phase of the Pending Changes request for comment. In this phase, you will be asked to offer suggestions and proposals to address specific concerns and problems with Pending Changes.

These ten questions were distilled down from the most-endorsed issues on the list of general positions and scope options that were presented in the last phase.

Do not edit this page to reply. You will need to create your own user subpage for your questionnaire, please use this format: Your username/PC Review Recommend Phase. Create this subpage and then add {{subst:Wikipedia:Pending changes/Request for Comment February 2011/Review Recommend phase}} to the page and save it. You should then have your own "copy" of the questionnaire to fill out. When you are done, save your changes and add a link to your subpage at Wikipedia:Pending changes/Request for Comment February 2011/Answers so that your results can be evaluated. Thanks for participating! The community will be informed when the results are posted. Please be patient, evaluating the large volume of replies anticipated will take a while.

How you can help

Please take your time and read through the concerns below. For each item, you are invited to offer a proposal that addresses the concern. Where possible, you are encouraged to provide examples, references, diffs and so on in order to support your viewpoint. There isn't a limit on the scope of your proposals; the sky is the limit, here. Most importantly, Answer as few or as many questions as you wish. All responses are evaluated, so any information you provide is helpful.

Once you've provided your responses, please encourage other editors to take part in the review. We stress that editors who didn't participate in the previous phases are encouraged to participate now - more responses will improve the quality of research, as well as increasing the likelihood of producing meaningful results. Once again, thank you for taking part!

Question one

Pending changes was activated on a trial basis. Although that trial has been over for some time pending changes continues to be used. Should we keep pending changes in use and continue discussing how it is to be used, remove it from all articles until there is a consensus based policy in place, or reject it entirely? (Note that even if you answer that it should be turned off you are still free to answer the remaining questions as you see fit.)

Note: These answers were mostly written 21 March 2011. I've updated them slightly before posting (02:48, 9 April 2011 (UTC)), but the content is probably already out of sync with more recent dicussions.

• Answer: Keep it on, declare its existence a done deal, and develop policy and improvements relating to it on an ongoing basis through discussion and experience with it active, just like with revdel or any other new feature.

Question two

The exact purpose of pending changes protection has never been clearly defined. Should it be used only to prevent edits that meet Wikipedia's definition of vandalism? If not, what other types of problematic edits may be rejected? Does it make a difference if the edit contains claims about a living person?

• Answer: It should be useable against arbitrary types of edits as decided by consensus on article talk pages on an article by article basis, as long as the edits don't require too much analysis or topic-specific knowledge from the reviewers. For example, PC was used (I guess through IAR) with reasonable success at Gödel's incompleteness theorems, a math article without significant BLP content. That article gets lots of good IP edits, but has also been under recurring sock attacks for many years by associates of Carl Hewitt, trying to spam the article with Hewitt self-promotion. The article has spent a lot of time semi-protected when the sock situation got intolerable,[1] to the detriment of legitimate IP edits.

  PC was a big improvement over that. Almost all edits I submitted under PC were accepted quickly without any fuss (one time, a reviewer reverted one of my edits by misunderstanding, but some discussion straightened it out). Unfortunately, some Hewitt spam also got accepted since it didn't look like vandalism, but PC at least slowed that down. My proposed fix is to let the PC reviewer dialog contain article-specific instructions for reviewers, settable by admins per talkpage consensus. In this case, the reviewer instruction would be something like "If you're not familiar with this article, please reject any edits mentioning Carl Hewitt, due to solid consensus that they are inappropriate and they are covered by an arbitration ban, and defer approving any such edits to editors active on the talk page familiar with the issue." In other articles it might be "per RFC at [link], please reject attempts to remove or resize such-and-such picture in the article" (or similarly reject "insert such-and-such picture"). This generally shouldn't be done lightly, of course.

Question three

Many users have expressed the view that pending changes is confusing or difficult to use. Have you found the current interface to be confusing or difficult to use? What improvements would you like to see to the interface? How could it be made more user-friendly? Please try to be constructive and specific rather than general, and feel free to read or edit the list of feature ideas on mediawiki.org.

• Answer: I thought it was ok as an IP editor. I don't remember exactly, maybe it could have used tweaking. I haven't seen the reviewer interface. I guess I could find some currently PC'd articles and try to edit them. To some extent this seems like a silly question, since it makes more sense to ask users of dewiki or wikibooks, whose experience with PC is much more extensive than enwiki's, or do some actual usability testing the way software developers do in the real world.

Question four

Users have expressed a concern that Pending Changes can discourage or even drive away inexperienced users or users who do not wish to register an account. Other users expressed the view that PC was less of a barrier than semi-protection and may encourage new users. Do you believe pending changes will prevent new users from contributing? Do you believe it to be more or less of a barrier than semi-protection? If it is kept, how do we balance this concern with the concern of preventing vandalism to Wikipedia?

• Answer: It's less of a barrier than semi-protection in my experience. I contribute sometimes at wikibooks where it's used extensively, and it's not a problem. (Hmm, maybe I'm confusing PC with FR--I'm not sure which is in use over there). If it's activated more widely on wp than semi-protection currently is (I'm not recommending for or against that), one possible benefit is that it might allow backing off the sensitivity of the revert bots and edit filters, which can both be very annoying. I'd much rather wait for a human to approve my edit, than get into an edit war with a stupid bot trying to figure out how to get past it. Here is one of my battles against an edit filter, from a few days ago. I had to study the filter code to figure out how to fool the filter, and most newbies would never be able to do that.

Question five

Generally, when should pending changes be used? Should it be considered in accordance with the existing protection policy on the same basis as semi protection, or should the bar for PC be higher or lower than that used for semi-protection? Please be as specific as possible.

• Answer: Hmm, not very strong opinion. I understand the desire to activate it on more BLP's than are currently semi-protected and I'm ok with that. I could see arguments either way for non-BLP but I think it's better to learn from dewiki's experience than to speculate. So I'd suggest surveying dewiki users about how it's been working out for them and what they do, and pay.less attention to uninformed enwiki opinions including mine. If I have to give an uninformed proposal: start with sliiiightly lower threshold for BLP's, equivalent threshold (admin discretion between PC and semi with preference for PC) for non-BLP's, switch from PC to semi if bad edits overload reviewers. Adjust practices as experience is gained. For Today's Featured Article (TFA), PC is surely preferable to semi. There used to be a custom of not semi'ing TFA unless the vandalism level was completely unmanageable, but that practice seems to stopped, I guess because it was unsustainable. PC might be a middle ground.

Question six

There is a general consensus that protecting biographies of living persons and other articles that contain information about living persons is a top priority due to the possibility of libel and real harm to real persons. Some have proposed that PC be used more liberally on BLPs or even suggested that pending changes protection should be added to all BLP articles. Should the standards for using PC be lower on BLP articles? What should the standards be for articles wherein the primary topic is not biographical but there is still content related to living persons? Should we automatically add it to all BLPs?

• Answer: Lower standards for BLP than non-BLP ok. Use on all BLP's: probably not necessary, most don't incur any significant amount of conflict or vandalism. I don't know exactly how RC patrol works but maybe there can be a special workflow for BLP edits of any sort, to make sure they all get reviewed. I think autoconfirmed users are probably as bad a problem for BLP vandalism as non-autoconfirmed.

  For highly contentious BLP's and other areas of conflict, I could even imagine "heightened PC" where all edits have to be approved by a second person (who could be any reviewer, e.g. any two reviewers could approve each others' edits). That would shut down a lot of edit wars right away among other things. I'm not right now advocating such a practice but I don't find the idea shocking. It's a standard practice in software development (extra eyes means fewer bugs), and we already require approval for changes to the wiki server code,[2] so I could imagine doing it to battleground or highly sensitive articles as an alternative to full protection.

  For mostly-non-biographical articles with BLP content: use PC if observed or likely problems warrant it.

  As another way to decrease adverse impact on living subjects, I've elsewhere proposed removing all BLP's from search engines (see "Noindex all BLP's" in collapsed thread here). I strongly believe we should do this, but the suggestion got no support. It would reduce the need for semiprotection and PC and have many other benefits and IMO no real drawbacks (the consequences that some people will see as drawbacks, I see as more benefits).

Question seven

During the trial period pending changes was added on an indefinite basis to many articles. Should pending changes be added indefinitely by default, be subject to the same restrictions as other forms of protection, or have some new criterion for determining length of protection? If so what should that criterion be?

• Answer: similar practices to current semi-protection, but higher willingness to leave it on indefinitely for contentious articles getting vandalized/attacked. Threshold of long-term semi-protection could be increased over where it is now.

Question eight

In the second phase, many users indicated that they believed that the standards for granting reviewer user right were too low, while others felt that being easy to acquire was a positive trait. What standards should be used to grant the reviewer right? What standards should be used to justify revoking it?

• Answer: Reviewers should have some experience and understand basic policy and basically know what they are doing. That was sort of the standard for RFA in the old days when "adminship was no big deal" (and we wore onions on our belts, which was the style at the time). Today, RFA is almost like an arbcom election. Reviewer standard could be something like the RFA standard in the earlier era, or a bit lower. A few hundred good edits, show general common sense in edit history, give reasonable answers to a standard interview conducted by any admin (don't need an RFA-like community discussion) showing knowledge of relevant policy, and ability to explain edit rejections in a diplomatic, non-confrontational way.

  To touch on another reviewer-related subject, I've come to believe that only editors with a reviewer flag or something like it should be able to create new articles or upload images. Editors who are only autoconfirmed can use AFC or FFU. A huge amount of pain and hostility comes from newbie articles deleted by NPP, and copyright problems on uploads. Something like 80% of new articles are deleted. All suggestions to relax NPP criteria (so that only 70% will be deleted, say) are in the wrong direction. The deletions are because almost all encyclopedic topics already have an article, and "create a new article" is just about the last thing we should be enticing newbies to do. For image uploads, this is a tragedy. We drove an extremely promising new editor away from the project by hammering him over NFCC problems with mechanisms designed for dealing with band spam. It would have been much better to not let him upload images at all without handholding and feedback from reviewer or admin, so he'd have gotten human advice about standard newbie errors, instead of getting clobbered with threatening templates left by bots (it looks like a bunch got cleaned off), and most other NFCC problems would be filtered out with much less acrimony. This is part of my rationale for the reviewer criteria described in the previous paragraph.

  We have 3+ million articles, we are no longer "here to write an encyclopedia" since we have already written it, and we're now here to maintain and improve it and fix errors and disseminate it. It is fine for that to be done somewhat differently than the earlier bulk-development phase.

Question nine

What specifically should be expected of reviewers? If they reject an edit, should they inform the user why the edit was rejected if the reason was something other than obvious vandalism? Should this notification be just in the edit summary, or should it be on the article talk page or the user's talk page?

• Answer: Burden on reviewers should be made low. The review dialogue might have some check boxes for reasons of acceptance/rejection (vandalism, contentious unsourced content, whatever), and a text entry field for optional further comments. I think user talk messages would turn into annoying spam if they happened on every edit, but if the reviewer actually had something meaningful to say ("I accepted your edit but it would be helpful if you could also add the exact date when that happened"), the reviewer could check a box to put the review comment on the user talk and the user might appreciate the feedback. The review dialog could also let the reviewer put a note on the article talk page, possibly to flag an accepted edit that for some reason needs further attention from editors more familiar with the article.

Question ten

Are we done yet? That is, do you feel the results of this questionnaire combined with the previous discussions at the RFC and elsewhere are sufficient to determine a consensus? If not, what should be done next? Should there be a poll, a more specific policy proposal, another RFC, or some other option that has not yet been tried?

• Answer: The main thing I see missing is more knowledge transfer from the WMF wikis that actually use PC on a wide scale. We slow-rolled implementation on enwiki so we could learn from other wikis' experience, but now we seem to be ignoring their experience.

Comment section

This section is for any further comments, suggestions, criticisms, or anything else you would like to say about either pending changes or this process that was not covered by the above questions.

This isn't the place to go into grand wiki-philosophy, but the new WMF "strategy" document got mentioned in connection with PC, so I looked at it, and I think most of its recommendations are exactly backwards of what they should be. As a project we seem to have lost sight of what we set out to do. We should refer back to our original goals, and fulfilling them points to a completely different strategy than what we seem to be doing, not particularly related to PC but about site operations, content goals and distribution, etc.

The battle over PC sounds something like one I heard happened over the introduction of semi-protection in 2003 or so, against quite a bit of opposition from the old-timers including Jimbo if I remember it right (it was before my time). It might be interesting to ask those folks if there lessons learned from that sound applicable here.