Jump to content

Wikipedia:WikiProject Articles for creation/RfC for AfC reviewer permission implementation

Add links
From Wikipedia, the free encyclopedia
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

A number of points can be drawn from the discussion. There appears to be (rough) consensus for Anne Delong's 6 point whitelist-only approach, however there is some concern that the word "banned" in point 3 is a bitbitey, and imprecise as we aren't talking about WP:BAN, and rough consensus to change that to something softer. No particular consensus on the exact softer wording, but that could be worked out later. Consensus to have a separate blacklist was not reached, as de-whitelisting is effective as a blacklist with less social stigma.

All users involved seem to recognize there's no technical way to enforce this in any real sense at this time, but the AfC helper script could be modified to not function unless they are on the whitelist. No current technical means will stop users from installing a "hacked" AfC helper or just manually moving pages. There is no consensus to use editfilter for technical enforcement at this time.

A point was raised that a negative userright such as "denymove" could be used for technical enforcement, but even the proposer suggested that was something that would require a new community-wide discussion and would likely be controversial, so as such, should be considered out-of-scope for this RfC, however a secure means of enforcement is wanted. --Mdann52talk to me! 13:56, 14 March 2014 (UTC) (non-admin closure)[reply]

Criteria / Preamble

[edit]

The Wikipedia:WikiProject Articles for creation/RfC for AfC reviewer permission criteria has been closed, and the closing editor, Mdann52, indicated that the criteria for an editor to become an Afc reviewer would be

  1. having an account that was at least 90 days old, and
  2. having at least 500 undeleted edits.

Mdann52 also suggested that another RfC would be needed to work out the implementation details.

Rationale

[edit]

There has been very little deliberate vandalism among Afc reviewers; most problems have been with good faith editors who either need experience with policies or who either haven't read or didn't understand the reviewing instructions.

With the proposed process,

  1. Any editor with the minimum time and experience can sign themselves up and then install the script, so admin time won't be taken up with handing out permissions and no WMF changes will be needed.
  2. Exceptions can be made by an admin on request for an editor with a good reason (such as a new account for an experienced user, a long time IP user, someone migrating from another language Wikipedia, etc.)
  3. Only one gadget and a couple of instruction pages will need to be changed.
  4. The success of this approach depends on the good will of potential reviewers, since the list will not be protected. However, in the past there has in general been good cooperation from new users when asked not to review; the problem has been to identify them before they have created too many problems. In any case we have 3RR to keep editors from repeatedly adding their names to the list.
  5. By keeping the tracking all inside Afc rather than asking WMF to create a new permission, if in the future Afc migrates to Draft or changes its processes, or even disappears altogether, there will be no residual effects outside the project.
  6. Inexperienced editors can still review manually, even though the instruction page would ask them not to, but we can always request a topic ban if this becomes a problem; no new procedures should be needed.
  7. If technically feasible, it would be beneficial to have the Afc Reviewer Script not function if the user's name was removed from the list after installation.

Proposal

[edit]
  1. That a prominent notice be added to the list of Afc reviewers at Wikipedia:WikiProject Articles for creation/Participants, inviting those who meet the two above criteria to add their usernames, and and requesting that editors who do not meet them to come back later.
  2. That if an editor does not meet the criteria but nonetheless is considered ready to review by any admin, the admin can add that editor's username to the list.
  3. That if an editor meets the criteria, but is banned from reviewing after a discussion closed by an admin, the banning admin can remove the editor's name from the list.
  4. That if an editor who does not meet the two criteria adds his or her own username to the list, any editor can remove it and refer the editor to the criteria.
  5. That the Afc Helper Script gadget installation process be modified so that, when invoked by a user who is not on the list, the script would not install, but instead present a message explaining that it is for the use of those whose names are on the list.
  6. That the Afc reviewer instruction page be modified by adding a message at the top directing new reviewers to the Participants page to sign up.

Support

[edit]
  1. Support as proposer —Anne Delong (talk) 06:28, 16 January 2014 (UTC)[reply]
  2. Support for it's minimalist drama-free approach. This proposal is to do only what is really necessary to correctly implement the previous RFC's outcome. I hope there are no technical impediments to adapting the AFCH script as proposed. Roger (Dodger67) (talk) 12:03, 16 January 2014 (UTC)[reply]
  3. Support - as proposed because it is probably the least bureaucratic solution. Kudpung กุดผึ้ง (talk) 12:19, 16 January 2014 (UTC)[reply]
  4. Support as a good-enough-but-not-perfect solution. Be prepared to handle cases of "bad reviewers who bypass the official helper script" on a case-by-case basis at first and watch for pattens that can be used to refine the process of dealing with "bad reviewers" as time goes on. davidwr/(talk)/(contribs) 23:04, 20 January 2014 (UTC)[reply]
  5. Support. Seems logical, sensible and reasonable. — Cirt (talk) 19:19, 21 January 2014 (UTC)[reply]
  6. Support - seems good. ///EuroCarGT 04:13, 25 January 2014 (UTC)[reply]
  7. Support Good idea. APerson (talk!) 17:00, 25 January 2014 (UTC)[reply]
  8. Support as a start. 78.26 (I'm no IP, talk to me!) 00:40, 26 January 2014 (UTC)[reply]
  9. Support. --Anthonyhcole (talk · contribs · email) 11:34, 26 January 2014 (UTC)[reply]
  10. Support. I like it. -- Ϫ 18:02, 26 January 2014 (UTC)[reply]
  11. Support Sensible and logical steps to start working on AFC. TheOriginalSoni (talk) 07:09, 6 February 2014 (UTC)[reply]
  12. Support It might be better if it instead checked some sort of whitelist on each review and then displayed an error message when a user tried to review without being on the whitelist. -- t numbermaniac c 06:43, 7 February 2014 (UTC)[reply]
  13. Strong support As per all above. It is what I've been thinking of. I didn't knew there's already a discussion going on here. Anupmehra -Let's talk! 09:36, 7 March 2014 (UTC)[reply]

Oppose

[edit]
  • Oppose WP:BUREAU. Can new users make articles. or not? If they can - help them; if they can't, then that's a direction that the wiki chooses to take. AFC is just a back-alley which allows it. The principle of Wikipedia is, "anyone can edit". It's unrealistic to expect new people to write new articles that meet the 1000 guidelines; hence WP:TIND, but it is very dangerous to allow a specific group of people to decide what is and is not appropriate - it goes against core principles of neutrality. 88.104.24.150 (talk) 22:44, 1 February 2014 (UTC)[reply]
Hello, 88.104.24.150. You make two good points. However, Wikipedia:WikiProject Articles for creation/RfC for AfC reviewer permission criteria has already been closed as approved - this is just about how to implement it. While this does limit reviewing to a specific group, the group is pretty big, including most minimally experienced logged-in editors. I disagree that it goes against neutrality - neutrality in Wikipedia is about the content of the articles. Reviewers are only accepting or declining articles according to already-established Wikipedia policies, and nothing in this proposal gives anyone a special ability to override these policies. In fact, one of the reasons for the list is so that if someone was showing bias (say, for example, declining or accepting articles based on political, religious, personal taste reasons, etc. rather than presence of reliable of sources, absence of copyvio, etc.), something could be done about it. —Anne Delong (talk) 00:14, 2 February 2014 (UTC)[reply]
To outline the rationale. first, there is no likelihood of requiring permission to make articles; an attempt at this was tried a few years back, as in essence,vetoed by the foundation as violating the core principle that Anyone Can Edit. The point of AfC is it provides a pathway for people to first ask for advice, which in principle should increase the likelihood that their attempt to make an article will be successful. But advice is not always needed: over the years thousands of editors have succeeded in making an article without formal advice--people do come here prepared to read and understand the basic rules before they start writing, Informal advice is also available from various sources, such as Editathons, which usually provide personal face to face assistance from experienced editors. second it does require greater skill to give advice on how to write than to write. To write an article, one need only with the rules that immediately pertain to that article, and most people have the sense to start with relatively simple and formulaic articles where there are models to follow. To give advice, one need know enough to perceive the problems in what someone else has written and to deal with them--and to know ones limits. Incorrect advice affects another person, not just oneself. We can let people be foolish if it affects only themselves--they have chosen to put themselves in a position where they must deal with the criticism. To let people give foolish advice and put other unsuspecting people into a position where those other people will need to deal with often quite sharp criticism is another matter--especially since the poorly-advised newcomers will usually be under the impression their work has received official approval.(And at present it's not the reviewers, but we admins who need to delete the material that must deal with their anger.) I personally suspect the requirements may prove much too loose, but the only way to tell is to see what happens when we implement it. DGG ( talk ) 17:38, 16 March 2014 (UTC)[reply]

Comments/Questions

[edit]

permission enforcement

[edit]
  • Is it possible for Editor A to change the preferences of Editor B to remove a gadget that has been installed by Editor B? Can an admin do it? If so it would not be necessary to change the Afc Helper script, only the installer or whatever makes items appear on the list of gadgets in "Preferences" —Anne Delong (talk) 14:34, 16 January 2014 (UTC)[reply]
    • It is possible to have the gadget be installed but refuse to present its hook in the place that the review item would be. The problem I see is that we could start to have edit warring over the "signup list" as to people who think they are qualified vs those who don't feel so. The WPAFC list then represents 2 purposes, those who consider themselves affialiated with the project and those who are wanting access to the AFCH tool. I would not object to a seperate list of AFCH tool users that is under full protection (with a very low threshold for changes)that is stealth transcluded to the WPAFC member list. Hasteur (talk) 15:33, 16 January 2014 (UTC)[reply]
      • I can't see how a disagreement could arise over who is qualified when the two requirements are very specific. Anyone who meets the requirements would only be removed after a discussion, which amounts to a topic ban. We have had an open list for some time and haven't had any trouble with edit warring. —Anne Delong (talk) 16:57, 16 January 2014 (UTC)[reply]
        • Hasteur and I have been following the recent arbcom case, which in a nutshell is a disagreement over who is qualified to be an AfC reviewer (everybody involved *definitely* has more than 500 edits). Agree with Hasteur that the reviewer-permission-(white)list should be distinct from the WPAFC-member-list. Plenty of beginners can be WPAFC members, and spend their time helping improve articles in the queue, adding comments, and such. C1 and C2 are meant to protect *mainspace* from improperly-approved articles; clicking 'approve' is not all their is to being in WPAFC. However, I disagree that the separate reviewer-permission-(white)list needs full-prot, pending-changes should be more than enough. Finally, I strongly disagree that de-(white)-listing amounts to a t-ban. They are *very* distinct concepts. 74.192.84.101 (talk) 10:37, 22 January 2014 (UTC)[reply]
    • Specifically the last point of "If the logged in user who installed the gadget is not listed in the AFCH-enabled list, don't present the hook." option is the least work. Of note, users don't have to be running the preferences-gadget version to get the tool. Someone can download the source code and place it in their user space (ala User:Theo's Little Bot/afch/afchelper.js) and attaches it to their custom javascript, they can run the helper without the preferences-gadget working. Of course if we catch discover users using a custom version without any real good reason (or using a modified version that bypasses the AFCH-enable check) we can ask the user why they are doing that, ask them to stop, or build a consensus that the deceptive use of tools is not supported by policy and should stop immediately. Once we've got that conesnsus in hand we can file a MFD to have the fork of the tools removed and warn the user that deceptive use of tools against community consensus is disruptive (with the appropriate following actions for Disruptive editing). Hasteur (talk) 15:42, 16 January 2014 (UTC)[reply]
      • Gosh, Afc reviewing is a lot of work, and I can't see that there would be many people who would go to all of that trouble to do it secretly, or that there would be many users with fewer than 500 edits who would know how. The whole point of the reviewer criteria is to reduce the problems caused by new editors who start reviewing in good faith without enough experience. The reason I suggested a technical block on the script is to automate that. Any removals of more experienced editors would be backed up by community consensus. These editors should respect that and not try to circumvent it, and if they do, Wikipedia already has processes for that and we shouldn't need to make the technical block foolproof, but really just a reminder. After all, any editor can move a submission out of Afc or make comments on a submission at the risk of being reverted. I can only recall a few instances of banning from reviewing since I joined Afc last year (Arctic Kangaroo and Bonkers The Clown come to mind), and I can't think of any who insisted on reviewing despite the ban. —Anne Delong (talk) 16:57, 16 January 2014 (UTC)[reply]
        • Even if they don't use a "hacked" version of the script, they still could do manually review AfC submissions, as that list has only effect for the script. Armbrust The Homunculus 03:57, 18 January 2014 (UTC)[reply]
          • I don't think any solution with just the tool will suffice. Most of the problem users I've seen have simply moved the pages out of AfC space and into mainspace. Jackmcbarn (talk) 19:22, 21 January 2014 (UTC)[reply]
            • I hope it doesn't come to it, but eventually Wikipedia may need to create a set of "negative user-rights" like "denymove" that override the normal user rights a person has. This would be a more refined case of "blocked," which is the normal user-rights minus useful things like being able to edit a page and just about anything else useful. davidwr/(talk)/(contribs) 20:03, 21 January 2014 (UTC)[reply]
              • MediaWiki supports this now. If we get consensus for it, it could easily be set up. Jackmcbarn (talk) 20:05, 21 January 2014 (UTC)[reply]
                • I knew the software could do it. However, I doubt the community will go for it - they will see this as a way of limiting the rights of certain editors, rather than viewing it as a way of saving those editors the pain of a block. In any case, I'm not convinced there is enough of a problem to warrant asking the community to endorse an involuntary "deny-move userright" right now. davidwr/(talk)/(contribs) 20:12, 21 January 2014 (UTC)[reply]
                  • Hello Jack, as I understand it, the point of the AfC-reviewer-list is merely to mitigate the bulk of the trouble. It isn't intended to suffice for *all* purposes, or to be bulletproof security. The goal is to improve practical security significantly, so that actual violators show up starkly. Locks on car-doors and car-ignitions are not perfect: thieves can break the car-windows to get in, and hot-wire the ignition. But the average editor will not be able to bypass the AfC-reviewer-list, just like the average person cannot operate a vehicle without the keys. We have NPP and other procedures in place to monitor for AfC bypass; this is about defense in depth. 74.192.84.101 (talk) 10:37, 22 January 2014 (UTC)[reply]
        • Anne, this is an incorrect statement, because it is incomplete: "The whole point of the reviewer criteria is to reduce the problems caused by new editors who start reviewing in good faith without enough experience." There is another point, which is to reduce the problems caused by spammers, sekret Wiki-PR employees, sockpuppets, and other slanderously slithery snakes whose name brings annoyance into the heart of SPI clerks. AfC submission declined by Anne Delong? No problem, just create SocketySock7583 and approve it yourself!
C1 and C2 are a moral-criteria for good-faith editors, and an operating-expense for bad-faith snakes
  There are good-faith AfC beginning-reviewers, with 5 edits + 5 days under their belt, who decide to 'help' by reviewing their friend's submissions about non-wikiNotable garage bands. These cause extra work for the rest of us, because we have to notice the problem. C1 and C2 and the list-o-reviewers ... enforced by P5 and with luck R7 ... help out here. The C1 and C2 criteria are intended to be a reasonably minimal expertise-and-experience bar, which is sufficient to keep good-faith editors honest, moral suasion not being enough (since people often don't read the helpdocs). After they've put in 500 edits, they have demonstrated a commitment to wikipedia's moral goals and will therefore probably do their good-faith best to make accurate and proper reviewing-decisions. If not, we simply take their name off the list... or more likely, just ask them to voluntarily refrain temporarily, until they have a bit better understanding of WP:N or WP:NPOV or WP:NOTPROMOTION or whatever.
  There are also bad-faith AfC abusive-reviewers, with 5 edits + 5 minutes under their belt, who 'decide' to review their sockmaster's WP:COI submissions. At the same time as helping keep good-faith contributors morally proper, the C1 and C2 criteria are intended to be a reasonably high operating expense for sockmasters, spammers, et cetera. It will be difficult for them to generate 500 non-deleted edits, because those edits will need to be *constructive* ones. As with any security-system, the downside here is that spammers will need to find another way around this barrier.
The snakes are the folks we need to worry about running modified AFCH scripts; the snakes are also vastly more likely to investigate direct-to-mainspace options (where NPP can notice them), and pull other WP:BEANS-related tricks. HTH. 74.192.84.101 (talk) 08:04, 22 January 2014 (UTC)[reply]

suggested proposal tweaks

[edit]
  • Uncontroversial methinks. P2 says admin_X can add editor_Y to the list, even if Y has <C1 and <C2. However, P4 says editor_Z can remove Y from the list for being <C1 or <C2. This sounds like a recipe for disaster.  :-)   To avoid the overhead, where every editor_Z that has watchlisted the page has to manually check the edit-history, to see whether Y was added by an admin, I strongly suggest the following change:

modified P2. That if an editor does not meet the criteria, but nonetheless is considered ready to review by any admin, the admin can add that editor's username to the list, specifying "User:$Y added by User:$X".

Point being, I want every editor_Z to be able to see, at a glance, that editor_Y is properly on the list. Especially since I'm gonna be editor_Y.  :-)   — 74.192.84.101 (talk) 09:07, 22 January 2014 (UTC)[reply]


  • Somewhat controversial. Per rationale (below... main reason is that the list is machine-readable and syntax mistakes could crash the AFCH-script for everybody), suggest that the list be a WP:PC-protected page (aka WP:FLAGGED), with additions to, and removals from, only possible for the 3700 editors which have the reviewer-userright.
rationale for applying pending-changes-level-one page-protection to the list
  R1 says that any editor can sign themselves up, so no admin-time will be taken up handing out permissions. I'm not against trying it out this way. However, look at P1. What if editors don't see the notice? Well, then P5 comes into play (and maybe R7), to keep them from installing the helper-script: instead they get an error-message, to sign up if they satisfy C1 and C2. What if they don't, but sign up anyways? P4 comes into play: somebody has to revert them, and refer them to the helpdocs (once again). What about P3, when an editor is removed from the list by the "banning admin" ... which is a poor phrase, more on that later. R1 says, the 'banned' editor can just add their own name right back! On paper, at least.
  In practice, I don't think we want admins to have to manually mess with the list each time. But I don't think we want the list to be wide open. Pending-changes is a good compromise; this will prevent folks with 5 edits from adding themselves to the list, without one of the 3700 folks with the WP:Reviewer userright confirming them first. It will also help enforce a consistent machine-readable format for entries in the list, which is very important (we do NOT want the AFCH-script to crash when somebody adds a misplaced glyph to the list). Note that pending-changes-protection would apply to both additions *and* removals; vandals would not be able to blank the list, for instance.
  p.s. I'm philosophically against WP:FLAGGED for mainspace (or semi-prot for that matter), such as used by deWiki... but for software-config-pages, it is an ideal compromise methinks. Making the list full-prot aka only-admins-can-modify-the-list is another option, which might improve security/robustness, but methinks is too strong until proven necessary. Others may argue that using WP:PC should not happen until proven necessary, but given that we want the list to be machine readable, and we don't want users with <500 edits adding themselves (these are of course *the* most likely to not read instructions... *or* to be socks), I think starting out with WP:PC isn't premature, just cautious.

modified R4. The success of this approach depends on the good will of potential AfC reviewers. , since the list will not be protected. However, in the past there has in general been good cooperation from new users when asked not to review; the problem has been to identify them before they have created too many problems. Because the list is intended to be machine-readable, and syntax-mistakes (or vandalism) might interfere with every AFCH-script user (see R7), the list will be under WP:PC-protection, so that additions and removals are still possible by anyone, but require the (otherwise unrelated to AfC) Reviewer user-right to confirm the change. In any case we have 3RR to keep editors with that Reviewer userright from repeatedly adding their names to the list.

We can always remove WP:PC from the list later, if it becomes a headache or a deterrent; I'd suggest an objective criteria, such as, if more than one potential-AfC-reviewer per week, has to wait more than one hour to get an answer, we remove WP:PC from the list. Average wait-time for WP:PC in mainspace is under five minutes (max wait as opposed to average wait), last I checked. 74.192.84.101 (talk) 09:07, 22 January 2014 (UTC)[reply]


ban versus de(white)list versus blacklist

[edit]
  • I hope very uncontroversial.  :-)   The language of P3 is inflammatory, or just pedantically incorrect. Per WP:NICE, we should not speak of the list in such a fashion. Unless R7 is actually implemented (which would obviously require that R7 is implementable in the first place), P3 as written also seems pointless: if somebody is *actually* community-banned or topic-banned from AfC-reviewing-duties, who cares if they are on the list or not? They've already installed the AFCH-script, so P5 has no teeth, why remove them from the list? Just block them if they violate their c-ban / t-ban. However, if in fact P3 is *not* talking about t-banned / c-banned folks, then we should not mis-use the terminology. Thus, strongly suggest re-wording.

modified P3. That if an editor meets the criteria, but is banned from reviewing after a discussion found unsuitable for the work at this time after an RfC closed by an admin, the banning any admin can remove the editor's name from the (white)list.

The point here is that, first of all, we don't want admins de-listing folks unilaterally, after dropping a template on the user's talkpage ("a discussion"). If the editor is *that* disruptive, the admin can always block them, right? Second, we definitely don't want to conflate delisting-from-a-(white)list with "banning" which has a very specific wikiMeaning in colloquial wikiJargon. 74.192.84.101 (talk) 10:09, 22 January 2014 (UTC)[reply]


  • Slightly controversial, since I'm not sure if we *want* to have a blacklist. As long as it is in the same exact machine-readable file-format as the whitelist, there is little technical reason not to have a blacklist to go along with our whitelist, but there may well be a social reason. Thus, tentatively offer this concept, for further discussion.

modified P3. That if an editor meets the criteria, but is banned from reviewing after a discussion found unsuitable for the work at this time after an RfC closed by an admin, the banning any admin can remove the editor's name from the (white)list. Depending on the ascertained consensus of the RfC, optionally the admin may place the editor on the AfC reviewer blacklist.

There is a massive amount of difference between the various things mentioned so far, as deterrents to improper behavior. Call them D1 through D7.
existing deterrents D1/D5/D6/D7, new deterrents D2/D3 added by the (white)list, and optional new deterrent D4 aka the blacklist
  1. An informal discussion, which ends with the editor voluntarily changing their behavior (perhaps abstaining from reviewing — or certain type e.g. BLPs — until such-and-such happens).
  2. An informal discussion, which ends with the editor voluntarily removing *themselves* from the whitelist.
  3. A formal RfC, which ends with the editor involuntarily being removed from the whitelist, after which they can still perform reviewing manually... or simply add themselves to the whitelist again, at some later date (such date perhaps being subject to criteria specified in the outcome of the RfC in question).
  4. A formal RfC, which ends with the editor involuntarily being added to a blacklist, after which they can still perform reviewing manually (or request an RfC to de-blacklist them).
  5. A formal AN/I or similar noticeboard-based outcome, which results in a (relevant) topic-ban, at which point it hardly matters if the name is on the whitelist or not, so there is no point in blacklisting them 'posthumously'... and in fact, there is a very solid WP:NICE and WP:NOTFACTIONS point to be made *against* such WP:POINTy blacklisting actions.
  6. An administrative block, which is preventative not punitive, and is the general-purpose tool which can help lead to coerced-yet-still-somewhat-voluntary behavior-changes.
  7. A community-ban or site-ban or arbcom-ban or similar, see above reasoning.
The point of C1 and C2 is to permit implementation of a whitelist (called "the list" throughout Anne's proposal because no blacklist was originally suggested). Whether we also want a blacklist, is the same as the question of whether we need deterrents D1/D2/D3/__/D5/D6/D7, or if we also need D4 available. The need for a *whitelist* aka 'the list' in Anne Delong's fine proposal, is already justified by the RfC which developed the C1 and C2 criteria, because D1/__/__/__/D5/D6/D7 was known to be not fine-grained enough.
  Personally, unless others are strongly in favor of doing this now, I'd vote to wait on D4 aka the blacklist... it might turn out we don't need one, and that D2 and D3 will be sufficient for keeping AfC running smoothly. We can always add D4 later, as long as the implementors of the (white)list keep the idea of future expandability in mind when they write the (white)list codebase. 74.192.84.101 (talk) 10:09, 22 January 2014 (UTC)[reply]
  • 74.192.84.101 has commented above that the purpose of the proposal is to protect mainspace from bad accepts. However, although this would be one result, in my mind it is not the main purpose. After all, mainspace has tens of thousands of editors and various processes in place to protect it. An (IMO) more important purpose is to protect new editors from bad declines by people who don't know Wikipedia's policies and/or haven't read the reviewing directions and use incorrect or spurious decline reasons. For example, someone who just marks everything with "see WP:NOT" without explaining what the problem is, or one that I saw this morning which was abandoned after being declined for not having enough sections. (Try searching Wikipedia to find out how many sections an article should have.) —Anne Delong (talk) 22:19, 22 January 2014 (UTC)[reply]
  • About the word "ban" - as proposer I would accept the removal of the word "ban" in favour of "found unsuitable after..." etc., if that is the consensus, although I personally feel that the former is more accurate and concise. My understanding is that a ban imposes a voluntary behaviour, avoidance of certain actions on WP., whereas "found unsuitable" implies a value judgement. However, perhaps the word "ban" also has negative connotations of which I am not aware. —Anne Delong (talk) 14:20, 24 January 2014 (UTC)[reply]
  • Hello Anne Delong, no, 'ban' is blatantly inaccurate, sorry.  :-)   See the "existing deterrents" green box, above. A person can be c-banned at AN/I, and t-banned or s-banned at ArbCom. But those are areas watched by hundreds of people. De-whitelisting is a unilateral action, of some local AfC regular(s), and we do not want to stigmatize it. Bans are very serious, and never unilateral local-consensus. Even *blocks* are very serious, compared to de-whitelisting. Admins, which means the ~600 actives this past month out of ~120k people who edited at least once this past month... aka one-half-of-one-percent of the folks here... are given the power to unilaterally block another editor, subject of course to unblock-reviews by other uninvolved admins. No. T
  There is no such thing as "imposing a volutary behavior". De-whitelisting *is* a value-judgement (is this person biting newbies?), and we need to try really hard, not just to de-stigmatize the language we use to speak of de-whitelisting, but to make sure it actually in fact *holds* very little stigma, in practice. See also below, on why we should have a blacklist, for social reasons, to help make de-whitelisting no big whoop. Animosity against AfC will not decrease, when whitelisting begins, unless we are exceedingly careful to make de-whitelisting a non-event. Informal D2 and formal D3 are very much distinct from D5 and D7. 74.192.84.101 (talk) 20:15, 31 January 2014 (UTC)[reply]
  • About the blacklist: If there is a whitelist of those for whom the script will work, I am confused about why there should be a blacklist as well. I prefer a simple solution that has minimum software dependency and maximum dependency on good faith and existing WP remedies against those who don't have it. Our technical experts (we love them and couldn't get along without them) can at times be irresistibly drawn to the lovely logic puzzle of the software solution - I know this because I am a programmer myself. However, we need to keep in mind the law of the hammer. —Anne Delong (talk) 14:20, 24 January 2014 (UTC)[reply]
  • I consider the blacklist optional. That said, if we are careful in how we define the whitelist, we get the blacklist "for free". Consider the case where User:SpammitySpamSpam sneaks onto the whitelist. They install the AFCH. Later, somebody notices, and de-whitelists User:SpammitySpamSpam. There are two possibilities. One possibility is that the AFCH only checks at install-time. In that case, we are too late. The other possibility is that AFCH checks the whitelist *each* time. In that case, all that User:SpammitySpamSpam has to do, is get onto the whitelist again. There is a record that they were *removed* from the whitelist at one point, right? But that record is buried in the edit-history. Furthermore, getting *added* onto the whitelist is supposed to be automatic, if you have 500+edits and 90+days, so User:SpammitySpamSpam will probably get back on. We can always banhammer them, right? But there will be a lot of edit-warring on the whitelist, I predict.
  The more important reason, to have a blacklist, is social. User:WP:MMORPG has 500+edits, every single one of those edits consisting of blatant-vandalism-reverts. They have 90+days. That means they get added to the whitelist, automatically. Later, it turns out they are awful at reviewing. So we de-whitelist them. But we don't put them on the blacklist, so there is less stigma to de-whitelisting. Does this make sense? Similarly, User:WP:MMORPG will remain a member of WP:WPAFC, if they wish, and are welcome to help out in the queue... just not using the AFCH tool to actually approve things, for the moment. Even if we never use the blacklist (folks like User:SpammitySpamSpam will be banhammered before we need to bother with the AFCH blacklist methinks), it still serves the purpose of destigmatizing the act of de-whitelisting. Plus, in terms of programmer-time, the blacklist implementation is effectively free, as long as the machine-readable-formatting is identical with the way we implement the whitelist. 74.192.84.101 (talk) 20:15, 31 January 2014 (UTC)[reply]
  • Which brings us to your zeroth point, Anne. "...purpose is to protect new editors from bad declines by people who don't know Wikipedia's policies and/or haven't read the reviewing directions and use incorrect or spurious decline reasons." The criteria C1 and C2 simply cannot do this job. They are obviously just rough secondary criteria; they give us an indication the person is somewhat committed to the project, but precious little hard data about whether the person is actually any good whatsoever at the practical craft of performing AfC reviews properly. But whitelisting is intended to be nigh-automatic!
  Therefore, de-whitelisting is the only mechanism for making sure that "inappropriate declines" are actually prevented: somebody who is an AfC regular (or a Teahouse regular or an IRC regular or where-ever the bitten editor goes to complain), will have to notice the fallout, and then solve the problem. At first this might be done with giving guidance to the other queue-reviewer, but immediate temporary de-whitelisting is my strong preference. In a future RfC, I'd like to propose some wiki-tools that make "watching the watchers" an automated process, based on direct primary criteria that measure the accuracy of the reviews statistically. However, that is for the future.
  For the present, if we want to prevent bad declines, we need to be able to de-whitelist at will, because not all editors with 500+edits and 90+days are going to be good AfC reviewers. That is the point of not calling de-whitelisting a "ban". That is the point of having a "blacklist" for actual spammers and other bad-faith actors. Because to avoid bad declines, we must de-whitelist folks that make bad declines. That is *not* banning them, or blacklisting them; it is a WP:NOTYET situation. Does what I'm saying make sense? Sorry about the lengthy responses, and thanks for reading, but as you can see, I'm pretty convinced the success of this proposal will depend heavily on ease of de-whitelisting. 74.192.84.101 (talk) 20:15, 31 January 2014 (UTC)[reply]

Technical feasibility

[edit]
  • You realize that this isn't possible to enforce right? Legoktm (talk) 21:17, 24 January 2014 (UTC)[reply]
    @Legoktm: What about with edit filters? I set up a demo of it on the beta cluster, and it seems pretty bulletproof. Jackmcbarn (talk) 21:25, 24 January 2014 (UTC)[reply]
    It's possible to bypass edit filters if you wanted to, and it would be a huge waste of the limited resources the edit filter has. Legoktm (talk) 22:03, 24 January 2014 (UTC)[reply]
    The behaviours that this proposal is aimed at restricting are generally not done by technically proficient people. The knowledge and effort required to circumvent the filters is beyond the capabilities of the vast majority of problematic reviewers. The system does not need to be absolutely perfect to be useful. Roger (Dodger67) (talk) 16:27, 26 January 2014 (UTC)[reply]
    Using an edit filter is the wrong approach here, from a technical perspective. Edit filters we made to prevent spam and vandalism, not enforce permissions for certain types of good faith contributors. If we want to technically enforce a permission, then an actual new permission should be made. I figure that the discussion is avoiding that because it involves making a bug request and asking staff members or technical volunteers (like Legoktm) to create it, which makes people worried it won't get acted on in a timely manner and without further discussion. But when you make a new permission like that, it's par for the course. Trying to route around that and use a restricted gadget plus edit filter is not the right way. Steven Walling (WMF) • talk 21:03, 28 January 2014 (UTC)[reply]
    The really sad thing is that the reason why such work-arounds are proposed and accepted is that the editing community has lost confidence in the WMF staff. We simply don't trust the WMF to do what we want, when we want, how we want. The WMF seem to have forgotten that they work for us, not we for them. Roger (Dodger67) (talk) 22:34, 28 January 2014 (UTC)[reply]
    I think you're over exaggerating a bit there. Do you not have confidence that the WMF is going to keep the site up? And I don't think the WMF works for "us", they alongside for the Wikimedia movement. That said, have you talked with any MediaWiki developers about implementing this properly? Steven's team actually seems like the right place to start. Legoktm (talk) 02:42, 29 January 2014 (UTC)[reply]
    I don't think the WMF works for us, either. Which means, Steven's team is not the right place to start. Because the goal here, is to try out some ideas, and see if they are helpful. Then if it turns out to be helpful, at *that* point we can ask the WMF to step in, iff needed. Tom Morris made a proposal that we use the Reviewer-user-right to bullet-proof the security of Anne's proposal, in the previous RfC. No WMF required, we already have the feature. But that step may not be necessary. There are two problems being mitigated here (notice I didn't say 100% eliminated). Problem#1 is spammers, who use socks to approve their AfC permissions, as a way to slip past NPP; and there *is* a fix to the userspace-to-mainspace-loophole, rumour has it, although not every NPP patroller uses the bugfixed tool. (Kaldari is the person who said this I believe.) Problem#2 is good-faith beginners that want to "help" wikipedia, but don't know WP:N from WP:NOTEWORTHY from a hole in the ground, don't know that facebook and myspace are not WP:RS, and so on. The 500+ and 90+ criteria will help mitigate both.
  Anne's idea that 500+edits and 90+days is primarily to ensure that reviewers have enough WP:CLUE to be doing the work, is misguided methinks, and the recent arbcom case seems to agree. We're just trying to impose a small obstacle for good-faith but not yet clueful enough beginners, so they do not approve their friend's garage band, and simultaneously, a real-world expense for spamming sockmasters. Later we can see whether more-bulletproof security is needed, as Tom Morris suggests. Later we can *also* see about implementing some kind of direct-measure-of-accuracy, which is my own suggestion from the previous RfC. But better security is a nice-to-have. Direct competence-criteria are orthogonal. Neither of those concerns, should keep this RfC from happening, which is about putting some partly-technical-but-mostly-socially-enforced restrictions on who can use the AFCH-helper-script.
  Maybe the same whitelist-technology will be useful to Twinkle/Stiki/Huggle/etc, which from time to time have the exact same sort of discussion. But the Twinkle folks had a whitelist in 2010, and then junked it in 2011, because it was overly complex, and rejected the idea again in 2013. Doing it *that* way saved the WMF from needing to get involved. Which is good, it saves donation-bucks, it saves dev-time. Only the best ideas should be implemented by the WMF. This idea is still in the alpha-trials-phase; it *might* be the Best.Idea.Evah but if it is, then some field-trials won't hurt, and if it isn't, then field-trials will show that to be the case. See also slakr's comment below, that we should NOT technically enforce this (as opposed to 'socially' enforce it), which is another reason why I also agree that seeking 100% security is premature. This is a mitigating mechanism, purposely not 100% secure, at present. 74.192.84.101 (talk) 19:28, 31 January 2014 (UTC)[reply]
I'd like to note that this is probably also a generally bad idea to enforce on the technical side anyway, per WP:IAR and WP:BURO. It's the same reason we don't forcibly restrict closures of *fd (or realistically anything else) to only people with +sysop. Furthermore, it's a fundamental fact that AfC is a kludge around article creation, so if anyone capable of creating/moving pages in article-space, well, creates/moves the candidate article in question, it's fundamentally goofy and unnecessarily bureaucratic to prevent them from closing it, because it's obviously close-able as "success." --slakr\ talk / 00:34, 29 January 2014 (UTC)[reply]
The problem with that is that people often create spam articles as drafts, where they're subject to less scrutiny, and then moved by sockpuppets to mainspace, thus bypassing NPP. The technical restrictions are more aimed at stopping that than stopping good-faith but unqualified reviewers. Jackmcbarn (talk) 00:41, 29 January 2014 (UTC)[reply]
Well, I mean, if the only reason is to prevent the occasional sock that slips through from... zOMG... circumventing a review process(!), then it seems a bit silly and control-freakish. Granted, I'm a relatively old bird in this discussion, so my threshold for what constitutes a "serious problem" versus what I label as "a bit silly" is probably quite a bit higher. *shrug* fwiw. --slakr\ talk / 01:00, 29 January 2014 (UTC)[reply]
That sounds like bugzilla:12363 or bugzilla:36930 to me (the latter which has had a patch sitting for 2+ months now...) Legoktm (talk) 02:44, 29 January 2014 (UTC)[reply]
Is it true that article moved out of Afc and into mainspace, either through the script or manually, are not checked by NPP? —Anne Delong (talk) 10:52, 29 January 2014 (UTC)[reply]
Essentially, yes. Jackmcbarn (talk) 19:26, 29 January 2014 (UTC)[reply]
Well, if that's the case, I don't think it's any fault of the Afc reviewers; the NPP could always choose to check them if they wanted to. —Anne Delong (talk) 20:51, 29 January 2014 (UTC)[reply]
I also believe it is the case, than an article moved from *userspace* into mainspace is not checked by NPP. There is a recent-changes-feed, and an improved NPP-feed, but there is not actually a pages-manually-mainspaced-from-AfC-feed, nor a pages-manually-mainspaced-from-userspace-feed. Perhaps those can be created, I don't know. But such issues are somewhat unrelated to the issue of adding a bit of security to the AFCH... if we *do* increase the security of AfC somewhat, relative to the security of userspace-to-mainspace, then we *may* need more efficient tools for alerting NPP about such activity. But fighting sopam is not a battle in whihc silver bullets can save us, methinks. Luckily, this RfC is not proposing any silver bullet solution.  :-)   — 74.192.84.101 (talk) 19:28, 31 January 2014 (UTC)[reply]

Manual reviewing

[edit]

Even if the AFCH script is put under a whitelist, what is to stop manual AFC reviewing (as I have done from time to time)? --Jakob (talk) 14:40, 6 March 2014 (UTC)[reply]

Hello, Jakob; there is nothing to prevent manual reviewing except that if an inexperienced reviewer is doing it badly, others can ask him/her to stop, and if this has no effect, request a topic ban from the admins. The proposal isn't intended to technically prevent people not on the list from editing, just make it more obvious that there is a consensus that they not do so. There are a lot of processes in Wikipedia that depend on the good faith of the individual editors. —Anne Delong (talk) 19:43, 6 March 2014 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:WikiProject_Articles_for_creation/RfC_for_AfC_reviewer_permission_implementation&oldid=1144527016"