Can we use the Talk page on a Draft article for discussions with the editor? It would be a convenient page to record discussions of content. Will using the talk page interfere with the scripts when the article is accepted? StarryGrandma (talk) 19:09, 7 August 2014 (UTC)
I am using the AFC Rewrite script, and it will move the talk page along with the article page when the acceptance happens. This should cause no problems for regular reviewers, but admins who are answering requests to overwrite an existing article name will have to check to make sure that no important discussion is being overwritten. My take on this is that review comments which are to be deleted when the article is accepted should be added to the submission page, but anything that should be kept (for example, links to references that could be added, suggestions for expansion in the future, comments from people who want to help with the article, etc.) should go on the talk page. —Anne Delong (talk) 20:17, 7 August 2014 (UTC)
Thanks. I agree that review comments should stay on the Draft page. I would like to keep the discussion of content for the article Draft:Janice (Jan) Richmond Lourie with the article. She is a very interesting artist and early computer science person. I don't want to accept the article until I've managed to rewrite some sections, but I need her help. StarryGrandma (talk) 21:06, 7 August 2014 (UTC)
StarryGrandma, Anne Delong: A somewhat slightly older thread which I think I've answered below somewhere. Some of us still recall the whole bunch of reasons why I and a few others fought for and got us the Draft namespace. This was one of them. KudpungMobile (talk) 09:43, 12 September 2014 (UTC)
Feature request Comment Suggestion
Would it be possible to change the script so that the reviewing boxes are a bit smaller? I mostly use the cleaning tool for right now, and find that I have to use the "arrow" key to access that portion of the script. My thought was is that if the main reviewer options were a bit smaller then all the options could fit on one screen and "scrolling" would not be needed. ArcAngel (talk) ) 03:37, 8 August 2014 (UTC)
ArcAngel, I'm not sure about Theopolisme's reasoning, but I guess the reason we put the cleaning tool in a secondary location was that less people used it. Therefore, per Fitt's law, the three primary buttons are what we guessed were the three most common actions. If we get feedback that the cleaning tool is used about as frequently as the three primary buttons (or that it's used more frequently than the "Comment" tool, which is my personal experience), we can swap it out or add it to the "primary" view. APerson (talk!) 21:02, 8 August 2014 (UTC)
Hrmm... I could see a change here. Some of us never use "comment"... What if it was [ Accept | Decline | User | < ] where User is whatever the user defines as the third option in the settings panel and < is still a way to access the other options? I think this could be fairly easily done, although, I don't really have the time to personally do it right now. If it was what the project members wanted, I'm sure something could be done. — {{U|Technical 13}} (e • t • c)19:36, 10 August 2014 (UTC)
Dear IP editor 174.90.223.130, the thing is, no-one has any idea who is editing form 174.90.223.130, so any checking is fruitless. Even then WIkipedia is unable to accept verification from the gentleman Dave McGowan (even in the flesh) because it requires verification in WP:RS, and, while we will believe and trust D McG, we cannot accept first party material. WHile this may seem bizarre, we are an encyclopaedia, and cannot work to press standards. FiddleFaddle17:01, 10 August 2014 (UTC)
This is a new user who has just reviewed and accepted more than one article, apparently using the helper script. I have left a message for Bulletrajabc on their talk page asking them to stop. I cannot see them in the list of participants or I would remove them. I will be notifiying them of the discussion here. FiddleFaddle18:33, 10 August 2014 (UTC)
Or perhaps a "Request to join the AfC review team" process, whereby applicants are screened by establish editors to see if they meet the criteria for participation in this project. ArcAngel (talk) ) 19:26, 10 August 2014 (UTC)
Apparently not. I am about to report him to ANI because he has once again moved Praneet sah back to mainspace acting as an AfC participant, so I believe it is an SPA attempting to get this non-notable person (perhaps himself) on Wikipedia. ArcAngel (talk) ) 01:24, 11 August 2014 (UTC)
Preventing editors who don't meet the AfC criteria from "abusing" the project?
Bulletrajabc has proven just how "vulnerable" the project really is to editors "abusing" the project. Even though that editor has neither the service time (6 days), nor the required number of edits (30), he still reviewed, accepted, and moved an AfC submission into mainspace (even though it was declined by an AfC participant).
It was really frustrating to see a new editor just come in and "flaunt" his ability to do that, when in Wikireality he should not have been able to. Not only that, but he attempted to put a reviewer userbox on his userpage (which I removed when I noticed it as he doesn't have that privilege), as well as having the ACFH helper script.
I think it would be easy to code the helper script to "block" those that aren't in the participants list from using it, but how do we stop others who are not in the participants list from accepting submissions (especially if they are still sub-par)? Of course I feel that admins and above should be/are immune to that restriction.
I'd like to get some thoughts from the project members as to what they think about this, and what can be done to prevent it from occurring again? ArcAngel (talk) ) 05:46, 11 August 2014 (UTC)
Protect the list of participants and have new reviewers apply and be approved. Despite having been removed form the list Bulletrajabc was able earlier today to use the review helper script to re-approve an article. I imagine there is some caching issue that allows this, but it is perplexing that a removal from the list of participants is not active at once. FiddleFaddle06:27, 11 August 2014 (UTC)
I was able to use the "gadget" script when my name was briefly removed (by mistake) earlier today, though I did get an error message, but the script was still functional. ArcAngel (talk) ) 22:15, 12 August 2014 (UTC)
Someone with the knowledge how could write a bot to revert and remove users who don't meet the criteria. It could repond quicker than a human and prevent script use. Would that be too bitey? For now though, protect. BethNaught (talk) 06:31, 11 August 2014 (UTC)
Beth, I don't feel that it would, because this project has qualifications, just like a real-world position would have. It's like a license, so to speak. The participants list meet the criteria for reviewing and accepting articles. Think of it this way - would you want an airline pilot to perform mechanical work on your car? Perhaps not as the pilot may not be "qualified" as an auto mechanic. The analogy applies to the project as well. If we don't uphold the standards set forth per the project, as was proven yesterday - any Tom, Dick, & Harry editor can just waltz in, create a draft, review it, accept it, and move it to mainspace without anyone being the wiser, and not only this project, but Wikipedia as a whole - could suffer from substandard articles. ArcAngel (talk) ) 06:44, 11 August 2014 (UTC)
History of this proposal to protect the page and have the reviewer script strictly enforce this (not sure they are all in chronological order, but I kind of tried to get them somewhat in order; there are also a couple discussions I remember happening but can't seem to find in the archives, so I'll disclaim this is not an all inclusive list - please feel free to add the other discussions as you find them, I even remember an RfC I can't seem to find where I suggested it be TE protected, and I stand by that whether I have that userright or not):
I'm not entirely sure what all the fuss is about. Autoconfirmed editors are welcome to create articles directly in mainspace. If someone accepts their own article they do so at their own peril. If an editor works at AfC and their experience isn't up to parr, they can be given advice or ultimately prevented from working here. Is this such a common problem to warrant spending all this time creating additional barriers to working here? Sionk (talk) 22:17, 12 August 2014 (UTC)
The user in question did not just accept their own article - in this and at least one previous "incarnation" (Technmaticity) they accepted other articles too, presumably thinking this would mask their intentions (see:this SPI for more). At that point you potentially have other new editors informed their article has been accepted, and created. Subsequently the review and acceptance might need to be reverted, and the article removed from mainspace again - not a very good or professional experience for the good faith new editor innocently affected, when they have submitted their new article for review by experienced editors, as we encourage them to do. Begoontalk22:28, 12 August 2014 (UTC)
It seems clear that the users in question acted in a manner that deliberately disrupted Wikiepdia. That's where the fuss comes from. I haven't checked, but I hope both (above and below) are now blocked for disruption. Along with any socks. If not, they should be. Bellerophontalk to me22:12, 14 August 2014 (UTC)
Now this is getting out of hand!
Apparently the word is out that editors who don't meet the criteria for being on the participants list can freely use the helper script - think of it as "open season on Wikipedia". Gnuuu is currently "going crazy" with it, along with moving pages around and causing "general mayhem" on the project. ArcAngel (talk) ) 08:20, 14 August 2014 (UTC)
Proposals
Per the recent stream of socks, I would like to propose a few solutions. The main 2 we have are either protecting the reviewer page furthur (ie. PC2 or full protection, as was implimented at first), or by creating an edit filter to detect users using the script without the experience needed. Any comments are welcome. --Mdann52talk to me!10:07, 14 August 2014 (UTC)
I'm not sure there is a suitable protection level available to us. PC2 is unavailable on English Wikipedia due to a lack of consensus. The only other options are full protection, which would lock out far too many legitimate reviewers, template edit protection - likewise and semi-protection, which would probably not be enough. Ritchie333(talk)(cont)15:14, 14 August 2014 (UTC)
(edit conflict) PC2 can't be used until there is a community wide acceptance to implement it, and I'm not convinced PC1 would be sufficient. Full protection is putting in a tack with a sledgehammer. Template editor (which I'm not part of) is the best available level. I also support an EF or revisions to the script itself to check minimum qualifications are met. If there was a reason for using the script without the minimum edit count or what not (ie sock account), then the checking for min edit count could be bypassed if the user had a specific user group (ie Reviewer). — {{U|Technical 13}} (e • t • c)15:22, 14 August 2014 (UTC)
My reading of the PC2 discussion is when there is a consensus to impliment it, per WP:IAR it can be used. There is a consensus to use it; Just no criteria as of yet. This (IMO) would be a good way to use it. However, an EF that checks a user has 500 edits when they use the script (maybe by picking up features in the es) would be a better solution IMO. --Mdann52talk to me!15:26, 14 August 2014 (UTC)
To clarify. There was an RFC consensus to implement PC2 if a set of criteria existed first. There was then an RFC that determined a set of criteria but in the process of doing so overturned the consensus to use PC2 at all. Therefor, there is not consensus to use PC2 at all on the English Wikipedia at this time. — {{U|Technical 13}} (e • t • c)00:42, 16 August 2014 (UTC)
(edit conflict) I'd support using PC2 but it's not yet been implemented. In lieu of that I'd say the list needs full protection. New reviewers can afford to wait and it prevent further misuse. Chris Troutman (talk)15:27, 14 August 2014 (UTC)
Full protection would work if there was a "requests" page, that admins checked and updated appropriately. I think my concern is we need to attract more experienced reviewers, and avoid putting any obstacles in their way if we possibly can. Ritchie333(talk)(cont)15:33, 14 August 2014 (UTC)
That would work, but why should only admins approve the requests? I feel than anyone on the participants list (they could be a "moderator") should also be able to "approve" new requests as one can easily check and see if the requirements are met. ArcAngel (talk) ) 16:55, 14 August 2014 (UTC)
Just throwing it out there that if you wanted to use PC2 narrowly construed for this purpose, you could probably get approval to do so at WP:AN or a similar venue if you clearly explained the situation. I, for one, would definitely support :-) GoPhightins!15:30, 14 August 2014 (UTC)
I'd recommend against PC2, not because I'm against PC2 on some philosophical grounds, but because I feel that Pending Changes is a poor mechanism for protection when the difference between what is and isn't a good change isn't going to be obvious to a reviewer without much context in the particular page being protected. I think you'll just get good faith "accepts" of additions of editors who don't belong here if we go PC2. *shrug* Maybe I'm just pessimistic, but, frustrating as it is, FP and a request board might be the thing. I don't feel strongly about it, and we definitely need to do SOMETHING, just ... humph. --j⚛e deckertalk17:15, 14 August 2014 (UTC)
I have semied the page for now. This seemed like the best (if imperfect) solution until we work out what we want to do. If anyone disagrees with me, feel free to ask any admin to change it back to unprotected.
I agree that strictly from a technical perspective, leaving aside any issues of whether or not pending changes, level 2 is approved for use, I suspect most pending changes reviewers won't know what criteria to use to accept an edit to the AfC reviewer list. Thus as things currently stand, with the current set of editors with permission to review pending changes, I'm not sure that using PC2 would achieve the desired goals. isaacl (talk) 19:32, 14 August 2014 (UTC)
Edit filter
Okay, I've looked through the edit filter documentation, and it's certainly technically feasible, and there seems to be some level of interest above. The correct predicates (e.g., user_editcount) are in the tools already, and relatively efficient (the test on the single matching URL should not significantly load the servers.) There's a clear sense already that some protection is necessary.
Shall we implement an edit filter that blocks changes to the AfC reviewer participant list page if the editor making the change has an edit count of less than 500?
This proposal is without prejudice to the use of other overlapping protection tools (semi-protect, pending changes, etc.).
If this proposal reaches consensus, I or another editor will follow up either with an implementation or a requested implementation at the edit filter request list. --j⚛e deckertalk18:48, 14 August 2014 (UTC)
Support - but only because I was the one who launched the RfC to get a set of reviewer quals established in the first place. That said, what we have here however, is merely a suggestion for yet another palliative - piling more scripts upon more scripts - instead of looking at a major revamp of the entire AfC process. Kudpung กุดผึ้ง (talk) 02:04, 23 August 2014 (UTC)
Oppose
Oppose simply on the grounds that there is no way to legitimately circumvent an EF for an editor that has more than sufficient experience and the qualifications met if they want to use a 'public' or alternate account. If you can find a way to allow that through the edit filter, I would change to support. — {{U|Technical 13}} (e • t • c)01:40, 16 August 2014 (UTC)
I think you might have misread the proposal here, so I might have a solution for your (completely reasonable) concern. This proposal only uses the EF to protect the participant list itself. I could, for example, place my own public-terminal account on the list using my regular account. Or, if I got caught not having done that, I could almost certainly email/phone/facebook msg a trusted editor who knows me in real life to make the adjustment to the validated participant list, etc. --j⚛e deckertalk02:30, 16 August 2014 (UTC)
Edit filter is a good solution to prevent new editors, but it doesn't solve the problem of editors new to AfC. PC2 (though controversial) would make the bar to reviewing higher. I support any protection available for the participants list, but I'd like to see this project tighten permissions even after edit filter is implemented. Chris Troutman (talk)17:04, 15 August 2014 (UTC)
Chris, my concern with PC2 here was the PC2 reviewers, in large part. I think PC in general works best when it is obvious to the casual PC reviewer, that is, the person who presses accept or reject, that there is a problem with a particular edit or not. We here at AfC are kind of a small part of the project, not everyone knows our concerns. On the other hand, reviewers who can accept PC2 pending changes are a pretty limited bunch, so it's entirely possible that I'm out to lunch. In either case, I'd be curious to hear your thoughts on this particular concern. Note: I wish there was a snippet of text associated with every pending changes protection that got displayed in front of the reviewer screen for every PC review. --j⚛e deckertalk17:31, 15 August 2014 (UTC)
@Joe Decker: I entirely agree with you. Personally I check every edit that I, as a reviewer, approve. I've run into other reviewers that have told me they approve any edit so long as it's not obvious vandalism. The latter case is the potential problem so I agree, it's not foolproof. I support the edit filter for that reason: that it prevents edits by users technically disallowed from being an AfC participant. 'Edit filter with PC2' would be better than one without the other.
That non-AfC participant reviewers might approve edits to the participants list is a larger problem that I'm not sure how best to solve. I'm a proponent of WikiProjects husbanding issues within their span of control but I know other Wikipedians see that effort as fracturing the larger project. Interestingly, 'edit filter with PC2' doesn't solve the problem of Wikipedians like Zach Vega (already a reviewer) gaming the system. Implementation of PC2 will increase demand for reviewer userrights and some userrights don't seem to be too hard to get, depending on which admin you hassle for them.
I also admit that I'm an advocate of PC2 and successful implementation on the participant list helps wider implementation across the project. Chris Troutman (talk)17:58, 15 August 2014 (UTC)
I'm actually a PC2 supporter as well, I've argued that there is a small but very useful window of utility for it for low-visibility BLPs which are badly vandalized, not frequently, over long periods of time by very dedicated detractors. The conductor whose wife keeps posting about his mistress, and the nightclub owner whose ex-employee has a grudge--both of these very real examples are people who are willing to go to the trouble, again and again, to create auto-confirmed accounts to push their agendas. Someday I'll convince people of this, but so far I've failed. I've got a multi-year year full protect on one of them right now, which is just stupid. --j⚛e deckertalk18:06, 15 August 2014 (UTC)
I still monitor the participants page, even though I'm no longer active at AfC (shame on me), so that's my justification for being here... That said, an edit filter is a very reasonable way of filtering unqualified participants, and provided the filter's warning template is appropriate, is probably less bitey than reverting as well. I still think PC2 is also suitable, despite being on the fence about it generally, and despite the problems above mentioned. BethNaught (talk) 18:37, 15 August 2014 (UTC)
None of this is going to stop people from simply inserting the script into their custom js. You are building a house of cards here. Gigs (talk) 18:56, 21 August 2014 (UTC)
I suspect the usual abusers are lazy, but you might be right. I have no illusions that this is a solid security solution. --j⚛e deckertalk19:00, 21 August 2014 (UTC)
Categorizing unreviewed articles
Back in May, User:Voceditenore proposed sorting AfC submissions by topic and by whether or not they had already been reviewed, in this discussion. Previously, User:Gigs made the same suggestion, and said that it could be accomplished with templates (here). These suggestions had support but were not implemented, as far as I can tell. User:InceptionBot already does topic sorting for drafts, but it would be great to have categories like:
We could do this manually, but then the categories would have be manually updated if you declined an unreviewed submission. Does anyone have any other ideas for how to implement this? --Cerebellum (talk) 19:32, 15 August 2014 (UTC)
@ArcAngel: hmm... Not easily, no. We would have to inset an extra variable into the template to count how many other templates had been placed, which would mean rewriting a lot of the template and the scripts and bots that go thorough AfC. Additionally, some users submit articles multiple times, so counting the submission templates on the page are not the most reliable method of working this out. --Mdann52talk to me!20:50, 15 August 2014 (UTC)
To be clear, I mainly support categorizing "virgin" submissions vs previously rejected ones. I don't have particularly strong feelings regarding topic sorting. Gigs (talk) 18:55, 21 August 2014 (UTC)
Catch copyvio!
In the last few days I've seen a couple of cases where easy-to-detect copyright violation had been overlooked by AFC revieweres, and editors were wasting time debating notability and/or searching for sources. Not all copyvio is easy to detect, but here's a case that is. If you're reviewing an article about some person or group, and if their web site is listed in the sources or external links, it should be automatic that you check it and if in doubt run it through Duplication Detector (setting the minimum number of words to 5, as the default of 2 will give too many false positives). This problem is so common that I'd honestly recommend making this check before doing any other reviewing -- you may save yourself and your colleagues a lot of work by sending such things to CSD with G12 (and G11 will often apply as well). --Stfg (talk) 19:54, 19 August 2014 (UTC)
I thought (perhaps naively) that one of the ideas behind the creation of the Draft namespace was that all newly created drafts would be checked by the COPYVIO bots. If it isn't being done, then it should be, but again this will only be yet another palliative for a largely dysfunctional system until something else comes along to replace the whole AfC thing. --Kudpung กุดผึ้ง (talk) 02:14, 23 August 2014 (UTC)
There are several bots which look for copyright violations, but they miss a lot of them. I understand that the reason is that they are not legally allowed to call Google as part of their code, and so they have no efficient way of figuring out which pages to check (if this explanation is misleading, feel free to improve on it). A proper check needs to be done manually. With so many people looking at the drafts, it's hit and miss which ones are checked when first created. When reviewing, though, obvious cases should be caught; sometimes reviewers just forget, or by chance check the only section that is not tainted, or in the case of one with previous reviews falsely assume that a previous editor has done the check. An idea: Can we have some kind of template that would add a comment-like line with a small check mark and text like "online copyright check performed on (date) by (user)". A check box could be added to the review script so that if there was not already one of these on a draft page, the reviewer would have to click in the box indicating that they had carried out the check. That would prevent a lot of duplicate effort, and make it less likely that the copyright check step will be missed. It still wouldn'r catch cases where someone came along after the check and added some copy-paste, or the text was offline or behind a paywall, or in a PDF, etc., etc. —Anne Delong (talk) 09:18, 23 August 2014 (UTC)
I presume you mean the calling the copyright violation detection tools directly. There are two that I use: Detector, created by Dispenser, and Copyvios, created by The Earwig. (This second one was working last week, but doesn't seem to be today; I prefer its visual display.) Neither one is completely accurate; you still have to run your eye over the two pages, but in obvious cases they can save some time. —Anne Delong (talk) 14:25, 23 August 2014 (UTC)
Well, there is User:Technical 13/Scripts/CVD.js that you could use too that will add a one click link in your sidebar that will scan the page for URLs and open both Duplication Detector and Copyvios tabs for each of them. There is rumor that copyvios has this functionality built in after me asking for it over a year ago, and that should greatly reduce the number of tabs opened by my script making it even easier to use. — {{U|Technical 13}} (e • t • c)16:44, 23 August 2014 (UTC)
What we have here however, is merely a suggestion for yet another palliative - piling more scripts upon more scripts - instead of looking at a major revamp of the entire AfC process. That said, does anyone realise just how easy it is to check for COPYVIOs? Problem is, you can give the reviewers as many buttons and boxes as you like, but just like at NPP, will they bother to use them? Kudpung กุดผึ้ง (talk) 17:08, 23 August 2014 (UTC)
Indeed. However: better automation of complete copyvio detection is a place where accuracy and speed can both be improved by the application of technology, and the WMF and devs should pony up whatever it takes to grow CorenBot's technology into something with a much lower false negative rate and something which is applied real time during Curation/reviewing. I don't see any value at all to using humans to perform completely mechanical checks. --j⚛e deckertalk17:41, 25 August 2014 (UTC)
Don't get me wrong, Joe - I'm all in favour of automating as much as possible the detection of COPYVIO. I'm only saying that where the COPYVIO bots don't/can't work, it's the easiest thing for a patroller or reviewer to slip a couple of lines of text into Google and see what it comes up with. That said, copyright violation is a major issue and one that concerns every single Wikimedia Wikipedia and the onus should be firmly on the Foundation to come up with a fully functioning bot rather than expect individual unpaid volunteers to do such major software development for free. It's what often happens though, and the Foundation sometimes even has the cheek to claim credit for someone else's initiative. Kudpung กุดผึ้ง (talk) 07:23, 28 August 2014 (UTC)
Oh, I didn't think you disagreed, this is just a long-time sore point for me, and one I'm reminded of every time I select hundreds of revisions to revdel from a long-ignored copyright violation. --j⚛e deckertalk16:39, 28 August 2014 (UTC)
Oldest submissions are too numerous
Please will reviewers concentrate on Category:AfC pending submissions by age/Very old to get it down to manageable proportions? The editors whose drafts are in this section are those likeliest to ask when they will be reviewed and have some justification in doing so. There were 270 at the last check. I know we aren;t all experts in all fields, but we can make quite a dent if we try. FiddleFaddle11:15, 23 August 2014 (UTC)
Indeed. One of them, incredibly to me, had absolutely nothing in the way of references or URLs. Usually those get quickfailed faster. To digress for a moment: How we can still lack a little bit of software that would automatically tell a new editor that references are a minimum requirement remains bewildering to me. --j⚛e deckertalk03:16, 26 August 2014 (UTC)
Good digression. I share bewilderment.
On a less happy note, I and others have just dragged this back down to 270 items in this category. If we can't handle this we are in danger of needing a further backlog drive, something that can be fun but that is also sometimes counterproductive.
I know the oldies are tough, but there is a satisfaction with getting the number right down, and, ideally, being able to accept quite a few useful drafts along the way. If you get tired doing the tough work you can always go back to the newest things that issue from the great fire hose of ordure and knock out a few test edits! At least we pretty much solved the empty submissions a couple of months ago.
I've just implemented a change that causes the "This is a draft Articles for creation submission. It is not currently pending review." banner to not appear if the page is in fact pending review. This should significantly reduce the number of people asking for help because they're not sure if their draft is actually pending review or not. Jackmcbarn (talk) 21:12, 26 August 2014 (UTC)
Thought I'd look at newly created pages and collaborate on those with due care and attention to the new people. I tried to do that here. In my opinion the drafts review process creates an unnecessary hierarchy -- I'd love to remain a peer and treat the newcomer as a source of wonderful knowledge, not as a reviewee or mentoree.
I had written a script which makes draft review things more personal by not using a template in review comments, but I couldn't figure out whom to approach to get it deployed, or how to prevent ugly templates on talk pages of people who submitted a draft for review. Look. It has black borders and a lot of redundant stuff and no personal message. Similarly the article review comments are just templates -- this is crazy; there should be canned replies, but also plenty of space to leave a specific unique comment. My script addresses those.
What I would like done is rework the existing templates and scripts in production to reflect on this philosophy:
The review comments may contain templates and should be encouraged to contain multiple reasons. A thorough review, with the reviewer pointing out multiple article issues, is a treat to the author.
The review comments should have easy means to type a personal message in, by hand. This doesn't have to be used, but it should not be 'reason -> custom' select click away.
The talk page message notifying contributor of the review outcome should be brief and to the point.
Make it shorter. Do not repeat "if you ask for help there, plz link to the article" - this is blunt and the target page already says so. Anyone can check contributions, as in majority of cases it's a first article.
Redesign appearance. Do not use black boxes, they're ugly like funeral.
Semi-automate instead of automating, so that reviewer can add personal note in easily. Do not put that much automated stuff in; I would personally only semi-automate the headline (link to an article revision being rejected or approved) and a part of the response ('Hi! The article is not ready yet; I've left review comments at the draft talk page.'). Open a dialog which shows headline and text to write to the contributor. The reviewer should have the flexibility to add anything he/she likes to both the headline and the text. For instance, "<article name> nice work on the history :)" could be a nice headline, and of course something meaningful appended to the contents of the message.
I know you have your views on this, but the thing is, I don't agree your script is better. Sure I'd agree on making it available for those who think like you, but not everyone does. Some people are more systemic, and the existing process is better for that. It's also better for those who aren't so experienced at reviewing.
I know standard text can miss the point, and a lot of people are down on it, but here's a defense. I'm not against more personalised responses becuase many submissions don't fully fit a standard decline reason. But everyone's mind is different, the standard texts have been through many minds and been honed and honed so they get the message across as clearly as possible to as many sorts of people as possible. Many custom reasons leave me scratching my head or saying "oh for crying out loud". They also lack the links to the appropriate help pages, unless the reviewer puts in a lot of effort.
I'd be in favour of a more flexible system that allows the reasons to be tweaked and mixed and matched or personalised. I can't envisage a system that does that without reducing the pool of revewers capable of using it to single figures. While I see your script works for you, I'm not convinced it would be an improvement for many others. Rankersbo (talk) 13:22, 27 August 2014 (UTC)
Rankersbo, have you tried the script? "allows the reasons to be tweaked and mixed and matched or personalised." and "does not lack the links to the appropriate help pages" are its two features. Although I'm yet to semi-automate or personalise the talk page messages; that's something I should be working on soon. --Gryllida (talk) 23:47, 27 August 2014 (UTC)
Sorry Gryllida I haven't- I was too put off by the output. I suppose I just don't like it. I should, but I don't tend to do enough coal-face reviewing to get the chance to put it through it's paces. I should at least try it, you're right. Perhaps you have improved it since the early days, or perahps it allows me to format the output in a way I prefer.
I do really respect your perspective, and the enthusiasm you have for improving things. I was just saying, despite that, I respectfully disagree. Rankersbo (talk) 08:58, 28 August 2014 (UTC)
Yes, it does allow you to format the output the way you prefer. It loads the canned responses from a wiki page. --Gryllida (talk) 09:05, 28 August 2014 (UTC)
Until a completely new new system is proposed, any new features, templates, functions, etc, to AfC are gong to be what they always have been - palliatives. It's not crutches or bandaids, or learning how to walk with one leg that AfC needs, what it wants is a completely new body - one that will also attract more people of the right calibre to the task of reviewing. Kudpung กุดผึ้ง (talk) 07:11, 28 August 2014 (UTC)
On a related note, one of the problems with the talk page message delivered by the script is that it doesn't actually say what is wrong with the submission. Given how many times we see help desk queries that are basically "Why was my submission declined?" despite it being clearly marked on the draft, we would do well to give a concise summary, staying well away from scary coloured boxes. I'll give Gryllida's script a go and get back to you. Ritchie333(talk)(cont)11:33, 28 August 2014 (UTC)
Or "my submission was declined without reason". There's always a reason, even if it's a bad one. I do tweak the decline template if it isn't appropriate- say the article was a duplicate of a main-space submission. Rankersbo (talk) 18:32, 28 August 2014 (UTC)
Ritchie333, drafts have a talk page. With each review, I'd add a new section to that (and link to it in the contributor's talk page message). This is again a nice feature for the script (I had written it before drafts namespace was widely adopted.) --Gryllida (talk) 14:55, 30 August 2014 (UTC)
On a side note, I am reviewing it for the Wikimedia Research Newsletter; see draft here. Feel free to comment or even edit directly; the review would benefit from a read by someone more familiar with AfC then me, plus I am a bit pressed on time and not sure if I can finish it on time for the current issue (next week) by myself. Cheers, --Piotr Konieczny aka Prokonsul Piotrus| reply here04:38, 27 August 2014 (UTC)
At last! Proof that Wikipedia was created solely to allow doctorates to be awarded because of research done on the ants here! FiddleFaddle08:19, 27 August 2014 (UTC)
I read through the report with great interest. As I've mentioned before, I primarily gravitated towards AfC because "it's better than smacking them with a template", but I can't face tackling the never ending backlog at the moment, so I'm working on GA improvements elsewhere. We need to really face up to the elephant in the room that we do not and will not get the manpower to tackle the submissions backlog effectively, and AfC drafts are (bar very few exceptions like, say, Rainthorpe Hall) not collaborative efforts. I like the idea of creating all new articles in draft space (though I suspect I'd waive that for autopatrolled editors and admins), and making more use of it. For example, Little Sea (band) seem to be stuck at AfD, but perhaps sending back to draft would be an alternative. @Piotrus: - what exactly do you need your report to look like? Ritchie333(talk)(cont)09:00, 27 August 2014 (UTC)
@Ritchie333: Primarily, I'd appreciate information if my lack of experience with AfC has resulted in any factual error in my post. Outside that, any copyediting and such would be appreciated; and if anyone feels like doing a major edit (or a separate review), you are welcome - I always appreciate friendly help :) There is no MoS per se, but check meta:Research:Newsletter#Archives for archives. --Piotr Konieczny aka Prokonsul Piotrus| reply here17:07, 27 August 2014 (UTC)
The paper is interesting. What I would like to know is, as with all research, the viewpoint of the researcher prior to creating the analysis. Has it reinforced a view or changed the view of the researcher? An analysis of the research needs to understand this fact.
AfC may or may not discourage new editor productivity. What it does most assuredly, is increases the quality of new articles when they are launched into main namespace. The incidence of summary deletion when patrolling new articles is akin to the incidence of pushing back an inadmissible draft for further work. The difference is that deletion is deletion, pushing back has the potential for getting a real article out if it.
One also needs to ask "Is WIkipedia important?" For many it is a repository of great knowledge, for others it is a load of biased tosh. For me as an editor it is a pleasant hobby. FiddleFaddle10:42, 27 August 2014 (UTC)
As the operator of HasteurBot (the one that does the majority of the G13 warnings/nominations) the bot explicitly has 2 interaction points with the "author" of a AFC page. First is at 6 months from the last edit on the page to let the author know (via a talk page message) that their work has become eligible for deletion under the G13 rule. It reminds them that they need to make a single registered edit to bump the last edit date and then be considered again if the page should fall into the "danger zone" again. The bot also gives the user (not IP address editor) the option of userfication (moving the page to their userspace) as an alternative for improvement. The second interaction is 30 days after the 6 month notification, if the page still hasn't been edited recently, then the bot proceeds with the G13 nomination (including notifying the creator of the page) for Admins to consider if the page meets the criteria for G13.
The problem with the current work process is that during our backlog drives we attract many editors and are able to get through our masive backlog, but once the drive ends (and incentive to review as many as you can) most of the volunteers either take vacations or stop reviewing again. It stems from the positive reinforcement conundrum that the article points at (nobody gives us a pat on the head when we're plugging along, but the wrath of all the heavens rains down when we decline something the "advocate" thinks is ready or pass something that a mainspace editor thinks was not ready).
We also suffer from the problem of editors getting involved with reviewing for specific non-NPOV reasons (reviewing so that I can get my article approved out) much the same way that DYK's Quid-Pro-Quo has motivated very perverse actions.
Benefits and pitfalls of "gamification" on Wikipedia and elsewhere could be an entire topic for a serious paper. Gigs (talk) 20:58, 27 August 2014 (UTC)
Piotrus - The authors of the paper completely miss the role that WikiProjects could (and do to a very limited extent) play in providing subject specialist reviews and assistance to newbie editors. Devising suitable categories for drafts - perhaps corresponding to the current stub category system - could potentially help that along by "automagically" bringing the existence of new drafts to the attention of relevant WikiProjects. This contrasting with the current (inadequate) practice of some regular AfC reviewers posting requests for assistance to WikiProject talk pages. Unfortunately many such requests go unfulfilled. Roger (Dodger67) (talk) 21:26, 27 August 2014 (UTC)
Piotrus - One of the most obvious blind spots in the paper to my eyes was that the authors failed to perform any sort of analysis of the actual merits of individual articles surviving different processes. They assume, a priori, that nearly any article which survives mainspace for 30 days is acceptable, or even *could be* acceptable with rewriting, under our policies. I believe this assumption to be laughably false, and moreover, if I'm right, an assumption which undermines the foundation on which the paper's primary conclusion is constructed. I have called out at least one WMF researcher on this sort of issue before, so it's a common mistake, but it is, I fear, a serious one. --j⚛e deckertalk00:36, 28 August 2014 (UTC)
Why not? Because I've looked at what gets through 30 days out of NPP, and the number of signficant problems that do not get identified is substantial, copyvios and non-notables in particular. An enormous amount of work then gets done a bit at a time on those, and then, a few years later, someone finds a copyvio and has to redact 575 revisions from some article that still hasn't demonstrated notability. That's why not. If the solution to AfC was to care less about crap getting into the encyclopedia, we could short-cut the process and simply accept anything that's been in the AfC queue for a week. We don't, and there's a good reason for that. --j⚛e deckertalk16:17, 28 August 2014 (UTC)
I don't particularly disagree with that. It took several years to find any issues - but until that time, the silence of the community de facto said it was okay. So what is your solution to NPP? My experience suggests that magically expecting somebody to spontaneously come along and fix this is sure to fail. Ritchie333(talk)(cont)11:22, 29 August 2014 (UTC)
More research and data mining are only going to tell us what we already empirically know about AfC, and it won't come up with solutions. Generally any research done by the WMF (or with its support or subcontracted/comissioned by it) is crafted to produce the results they want to hear, and which they want the volunteer community to believe. I have personally made the Foundation aware of one huge blunder it was making, and the community through its actions, has made the WMF critically aware of others.
The AfC 'community' is well aware of the shortcomings of the sytem. This is manifest through the perennial discussions about it, and the need (such as here) to constantly reiterate on what has already been discussed many times over.
The AfC 'community' is resistant to change and/or the introduction of a new sytem to replace it. (I will reserve my opinion for the moment on why this is), and hence the many requests for new features, improvement to existing ones, constant dialogues between users about what to do with certain submissions (although this is not necessarily a bad thing), and some monumental flare-ups and bad faith that don't help anyone.
All new articles will never pass through AfC or any other similar system that requires a review or even a minor delay before they are published in mainspace. We tried this with WP:ACTRIAL - a proposal that received overwhelming support from the en.Wikipedia community but was quashed by the WMF as conflicting with the apparent core policy that all registered editors should be permitted to publish new articles spontaneously and immediately.
Wikipedia still lacks a proper landing page for new users who are about to create their first article. This is the most glaring omission in the project's entire history since January 15, 2001. Clearly informing people up front of what they can and cannot do here would prevent the creation of most of the obviously inappropriate pages. This omission is however deliberate because it is felt again that the slight delay by having to read it would lose many potential new authors. The founding philosophy is 'let all and any pages be created immediately, and we will filter the crap out later.' Unfortunately, today's Wikipedia can't function on such a fundamental premise - with most of the traditional encyclopedic articles having been created already, nowadays the crap is a high percentage of all creations and submissions, and and there is just not the person-power available to cope with it.
Many AfC drafts, like many new articles that go through NPP, are created by extremely lazy people who assume that it is the duty of some real or imaginary squad of permanent Wikipedians to repair, improve, or expand such 'articles'. There is no such squad, and it is an affront to the voluntary work of the mainstream maintenance workers to expect them to do so. The disinterest of the various en.Wiki projects can probably be attributed to this.
It's quite obvious, based on administrators' experience with requests for Rollbacker, and Reviewver rights that only the lure of a collectible user status will attract people to the task of reviewing AfC submissions (and also, for that matter, NPP). Unfortunately such minor user rights often attract the wrong people, namely those who see them either as a reward for industrious behaviour or as a stepping stone for climbing up some greasy pole.
Some users who have been deeply concerned by the way it works have been able to get some things created or introduced for it (Draft namespace, qualifications for reviewers, helper scripts, bots, help pages, etc), but all these bolt-ons have generally failed to attract more reviewers of the right calibre to the process, improve the quality of reviewing, and reduce backlogs. Indeed, paradoxically, many of those features have actually created even more work for the AfC 'community'.
AfC is not a process mandated by policy. Perhaps the abolition of AfC altogether may be the answer. One problem with that is that some Wikipedians might lose their sense of 'mission'. Another is that while such a move would have the advantage of putting a final stop to IP creations, it would however add significantly to the workload of NPP - a far more important process but one that still has (although not entirely dissimilar to AfC) huge problems of its own.
I've read the report, the main reaction was "wow, how thoughtful and reasonable." There may be shortcomings, but the approach in that respect is admirable.
I think part of the problem with AfC accepting change is that people tend to stroll in here and shoot their virtual mouths off. Anything from flying off the handle to being over direct and abrasive. From reactions to objections you'd think WP:CIVIL is optional, and anyone having problems with abrasive behaviour was violating WP:AGF. This is untrue.
I've read WP:AGF. The first line is a reference to be civil. (Gryllda is a notable exception of someone requesting change positively; I respect that users enthusiasm and positivity and desire to improve things- I just disagree with their point of view.)
It's not a problem with those on the fringes, we can be uncivil to each other- a bit too brusque and direct. Within the project we need to respect those who give their time to help, especially when in their newbie enthusiasm they are making way too many mistakes.
That said, I have been impressed with the patient, civil and sensitive way some of the more agressive and heated complainantsnhave been dealt with. Not enough for the complainants for whom "gosh you are right, we are incompetent idiots and will do as you say immediately". I raise a smile when a ranter raises a complaint, and has the situation politely and pateintly explained to them, and yet they storm off saying how supercillious and patronising we are.
We all need to accept two things, that when people see things differently, they are not necessarily "resistent to change" but just have another point of view. And that when we get heated and brusque about things, the resistence created is sometimes our own fault and not the bad faith of the reader. Rankersbo (talk) 08:50, 28 August 2014 (UTC)
Just to add my own data point which I feel illustrates the problems highlighted with the report very well - have a look at Jacob Weinberg and the contributions of Emausner (talk·contribs). To briefly summarise, this user (a relative of a notable, but neglected, early 20th century composer) has been trying to create the article for well over a year, and there is no obvious evidence the advice given to them en route (particularly declining an AfC submission as "an essay" despite having this Chicago tribune source, among others) has been at all helpful or useful. Ritchie333(talk)(cont)10:27, 28 August 2014 (UTC)
Rankersbo: I'm afraid I have to disagree with writing off concerns about this study as "a few flaws." It is my belief that the primary "inding of this study is not actually shown by the study, due to the severe observation bias introduced by the 30-day metric for what is an isn't an okay article. This isn't a correctable with a handwave, it is a fundamentally damaged foundation for understanding, and the sort of error that would have been caught by any sort of meaningful peer review, were this actual academic research. Much of the rest of it is excellent, and I suspect that many of the results are correct, but the 30-day test more or less begs the result. --j⚛e deckertalk16:24, 28 August 2014 (UTC)
Oh, and also -- I'd be really interested in discussing the design recommendations of the paper further -- or BETTER design ideas the community has come up with. (I've gotta go read carefully all the above, and point it out to my coauthors Bluma Gelley & Aaron.) Now that the Draft space is in place, and in common use, I think the time is right. Jodi.a.schneider (talk) 12:50, 28 August 2014 (UTC)
Jodi.a.schneider FYI: On slide 50, there's a missing path from declined back through mentorship (which is what the decline does in providing "It needs XYZZY" feedback) and then back and then back into pending. If the user doesn't respond to the feedback the reviewer provided (and lets the work go unedited for 6 months) the draft eventually gets deleted as an abandoned draft.Hasteur (talk) 13:09, 28 August 2014 (UTC)
Thanks, Jodi, I'll take a look. Sorry to be so harsh about the 30-day test you use in my quotes above, but finding the right answer here is pretty important to the encyclopedia. Best, --j⚛e deckertalk16:28, 28 August 2014 (UTC)
I agree that the 30-day test could be improved on. It's a simple approximation (of the "envision a spherical cow") variety to start with. It assumes that (1) everything in Main space gets views (2) Every time something is viewed, it has a chance of being deleted/nominated for deletion. Not sure what would be better -- only counting pages that have a quality rating (which suggests that a Wikipedia looked at them)? or...? Jodi.a.schneider (talk) 21:48, 28 August 2014 (UTC)
(Responding to Kudpung above): I pretty much agree with everything you said. I'll add some nuance below, but the context of this reply is "yes, ... *and*", not "yes, *but*"
The proper landing page is a big deal. More or less, the thing we fail to do for new editors that I notice most is get them to understand, before they expend a great deal of effort, what our inclusion (notability) criteria say. Figuring out how to accomplish this, with a combination of deferring new editors until they've learned a bit, and much better user-friendly explanations of our policies, and perhaps direct assistance *before* they go to writing ... seems imperative for any good outcome.
Your last comment, about retiring AfC entirely, is on-point, I have also been thinking overnight about a process where we use draft space only for the period where we are assessing whether something needs to be quickfailed. If we could keep deeply promotional, copyrighted, attack/BLP and nonsense from getting into mainspace, allowing more non-notable stuff to end up there and be handled in a more eventualist manner might be a "middle way" that preserves the NOINDEX benefit of Draft space while substantially reducing the backlog. Almost all the hard problems of AfC reviewing are notability-related. --j⚛e deckertalk16:36, 28 August 2014 (UTC)
Landing page is a really big deal. Do you know that the "page creation" interface you get depends on how you get to the page? (Redlink vs. search vs. userspace). That drives me nuts! Having ONE interface and doing lots of A/B testing on it with new editors would really help. Jodi.a.schneider (talk) 21:48, 28 August 2014 (UTC)
I think rather than educating new editors, we want to try to educate readers wherever possible. To me, that means putting quality signals directly into the article (and not necessarily just its Talk page). Jodi.a.schneider (talk) 21:48, 28 August 2014 (UTC)
Landing Page (arbitrary break)
I sometimes feel as if I just don't have the energy any more to bring this up again (and this is the kind of exasperation that forces users into retirement) but here goes:
Most of my personal encounters whether official or in passing, with the most senior WMF staff are generally positive. Nevertheless there is sometimes a feeling that thier comments are of the patronising boss-to-underling type such as "Yeah, good thinking Kud', we'll take a look at that." Very often they actually do, but in the case of the landing page they made a token start (which was neverthelss very impressive) and then delegated it to junior staff who when all was quiet and the dust had settled they quietly not only swept it under the carpet, but by stages, deliberately moved it and archived it many times so that it was so deeply buried and well hidden from view that only a Google search reveals it today for those who still remember what to look for.
History:
As a direct result of WP:ACTRIAL which was proposed specifically to address the issues surrounding NPP, a two-part consolation prize for the way they mishandled this community initiative was offered by the Foundation. One we got, and the other, the landing page, suffered the fate retold above :
The new New Pages Feed and its Curation Toolbar, nevertheless an excellent suite of software, but which however ignored and failed to address the major issues: inexperienced patrolllers and too few patrollers.
The promise of a genuine landing page for would-be first-time article creators, the object also being to stem the tide of unwanted articles in order to releive the pressure on NPP, and to encourage new creators to write articles that conform to our standards and guidelines. In short, it was to be a replacement for the Article Wizard.
MediaWiki: Graphic created apparently by Howie Fung. No devbelopment but last edit to the page on 9 November 2013. The team included: Benny Situ, Ryan Kaldari, Ian Baker, Brandon Harris, Oliver Keyes (Ironholds), Howie Fung, Dario Taraborelli, Terry Chay.
What this all clearly documents is the apparently totally disorganised way the WMF functions. So many people have been involved on this project, now approaching the end of its 3rd year, that through many many staff changes over that time, nobody really knows where the project is at now, who is supposed to be doing what, and every employee in the office except the janitor having a title of Director of this and Manager of that, but nobody actually in charge. It took the WMF 6just over 6 months to build the complex NPP scripts, what is holding up the development of the new landing page that could even be rolled out across all Wikis?
I feel your pain, Kudpung, I really do. Such a shame ACTRIAL was torpedoed so I still have to revert badly called CSD A7s and hope the editor doesn't leave Wikipedia. If you want to run a successful software company (such as Microsoft, Google, Amazon, eBay, Apple etc) you have to start with seriously excellent techies at the top who know C and Lisp inside out (including pointer arithmetic, tail call recursion, first class functions, race conditions, leaky abstractions) in their sleep, and can write any code you throw at them in no time at all. That's the only way I know how to succeed - there are many ways however to screw it up. Ritchie333(talk)(cont)14:56, 29 August 2014 (UTC)
There's a big difference between studying Communication Science and Information Technology. Programmers are generally very good but only if a project manager comes along with a concept for something to be realised in code and stands behind them and tells them what is wanted. The problem within the WMF is that it assumes programmers can do both. They can't, just as any webmaster knows, for example, that the best knowledge of php does not a graphic artist par excellence make nor the best author of an instruction manual for a person of average intelligence who is not a programmer. (this BTW is why after the migration from the ToolServer to Labs, we now have tools that work better, but whose GUI is hopeless to look at). The current Article Wizard probably loses as many potential editors as it gains. What AfC gets are the left-overs. In contrast, and quite unusual for a WMF development, what we got for NPP was a software package that not only works well, it does what we wanted, and is nice to look at. Now if the same team were to work on that landing page that Jorm started designing... Kudpung กุดผึ้ง (talk) 17:07, 29 August 2014 (UTC)
Review & cleanup for some long-time AfC drafts?
I've done some cleanup on a couple AfC drafts. They still need some more work and another look-through, if anybody's got the time:
I've done something which may help Draft:Jason Agnew long-term, and added some projects on the talk page. The next thing to do is find some way of working out what drafts have projects, and set up an alert bot to post them to relevant places. This link shows pending drafts that may be of interest to the projects. If somebody more au fait with the API can tell me how to do it via that, I may be able to cobble together a project notification mechanism. Perhaps Hellknowz (talk·contribs) or Headbomb (talk·contribs) could put it into AAlertBot (talk·contribs) by extending the bot to cover "Draft talk". It would go some way to solving one of the design recommendations in Jodi's report. Ritchie333(talk)(cont)13:53, 28 August 2014 (UTC)
The WikiProject banner system's "class=????" parameter does have an option to implement "class=Draft" in addition to the other familiar class categories such as Stub, C-class...GA and FA. Because it is optional and not well publicized at all, I know of only one WikiProject which has actually bothered to add it to their banner parameters - WP:WikiProject U.S. Roads/Assessment#Other classes. Who do we need to lobby to add the Draft class to the default standard set of class parameters for all WikiProject banners? With just this single change WikiProjects will almost automagically become drawn into the draft creation and assessment process. The initial reviewer simply adds relevant project banners to the draft talk page, including the "class=draft" parameter, and then the magic happens - the draft gets listed on the WikiProject's page. Currently if the project has not implemented the option (AFAIK that's all of them except U.S. Roads) the page simply gets tossed onto the "NA" pile, where it is inevitably ignored. Roger (Dodger67) (talk) 15:49, 30 August 2014 (UTC)
I think the best answer is "if you build it, they will come". I keep an eye on Wikipedia:WikiProject Rock Music and I'd be happy to try and class drafts there. So many musician / band drafts get created, it sounds like an ideal guinea-pig project. I've added a feature request to Article Alerts here, but I'm not expecting a rush. I can probably knock up some PHP code myself to handle all this, but I've got no way of hosting it - could @Technical 13: or @Hasteur: extend their bots to cover this?
In any case, I don't think we need "class=Draft" at all; either a page is in the draft namespace (in which case it's a draft) or it's in mainspace (in which case it's not). Just adding the project template would be enough, and it's something I could see being added to the AFC script in time, giving the reviewer an option of project / task force assessment. Ritchie333(talk)(cont)09:39, 1 September 2014 (UTC)
Without the "class=Draft" parameter the draft is simply added to the WikiProject's "unsorted" list and will not be recognized as a new draft unless editors actually bother to look through the usually very long list of unclassified pages. The US Roads project's use of the Draft class parameter gives them a neat easy to find list of current drafts instead of having them scattered randomly among unclassed pages - which for the larger projects can be many thousands of pages (WikiProject Biography currently has 173,788 such pages) of which only a small fraction might be drafts. Roger (Dodger67) (talk) 12:08, 1 September 2014 (UTC)
Yes "most projects seem to not recognise the "class=draft" parameter" is exactly the point I've been making all along! It's an optional parameter that was added when Draft-space was created - IMHO it should be one of the standard parameters just like "Stub, Start,...GA, FA" are. The fact that "people won't necessarily remember to do that" is not a valid reason to actually deliberately prevent them from doing it. In any case we AFC reviewers can do it at the first review of a new submission if the draft writer has not already done so - just make it a step in the workflow. Not having these options activated by default rather defeats some of the entire rationale for the existence of Draft-space. These are the things that are supposed to make it superior to the old "WT:Articles for creation/draft" way of doing things. Roger (Dodger67) (talk) 07:05, 2 September 2014 (UTC)
I found out how WikiProject U.S. Roads implemented the parameter - see these diffs [2] and [3]. BTW this method is not dependent on AfC - the parameter could be added to all drafts, not only those submitted to AfC. -- Roger (Dodger67) (talk) 09:07, 2 September 2014 (UTC)
The actual method for enabling on a per-project basis varies according to what is in the |QUALITY_SCALE= parameter. The method used by Canada Roads only applies when it's |QUALITY_SCALE=inline. For |QUALITY_SCALE=subpage, you would add |draft=yes to the WikiProject's "/class" subpage like this. For |QUALITY_SCALE=standard and |QUALITY_SCALE=extended it can only be done by changing to either of the others, unless a general change affecting every WikiProject is made, which means amending {{class mask}}, see Template talk:Class mask#Protected edit request on 1 September 2014.
On a more pragmatic note, I think turning it on a per-project basis makes the most sense. While I'm happy to watch over drafts coming in for musicians, bands and albums (as I de facto have done anyway), many projects are near dead, and just categorising incoming drafts there may not have any practical effect whatsoever. So why do it? Ritchie333(talk)(cont)13:21, 2 September 2014 (UTC)
I've knocked up a tool that demonstrates what I mean. If you go to Special:MyPage/skin.js, add a line importScript("User:Ritchie333/drafts.js"); and go to a project page, you'll get an extra option "Draft list". Click on that and you'll get a list of outstanding drafts. It doesn't distinguish between unsubmitted, pending or declined submissions yet - that'll involve parsing the actual wikitext, but it's a start. At the moment, one example I know works is on Wikipedia:WikiProject Metal, which gives me Draft:Dead Waves (band). Most project pages don't have anything - yet. Ritchie333(talk)(cont)15:43, 1 September 2014 (UTC)
Hi, I'd like to propose a backlog drive under the rules last used. Can anyone tell me how I can do that? When replying, please extend me the curtesy of pinging. Cheers, Thanks, L235-TalkPing when replying05:06, 2 September 2014 (UTC)
I feel we should modify the rules to favour reviews of the oldest submissions. Clocking up points is easy at the outlet of the great firehose of ordure. I'm inclined to disqualify reviews on any items submitted for less than a week from scoring points at all. Our problem is the backlog, not the recent submissions.
I would also disqualify re-reviews which do not have another reviewer between two by the same reviewer from scoring any points at all. More eyes than one editor's provide better reviews when the process is iterative
I also feel we do not need it to run for more than 14 days.
I make these statements from the position of having been, much to my amazement, the runaway leader of the June drive. I seriously should not have been. While I'm an experienced editor I had very little experience as a reviewer. I gained substantial experience and expertise (both) during the drive. During the last 2 weeks of it I relaxed in the recent submissions area. It was easy to review a substantial amount of trash.
One great thing to come out of that drive is that we fixed blank submissions (easy to score points on those) so that you have to try really hard to make one. I'd like to see Test Edits mopped up automagically, too. Another drive might give us hints on how to handle that.
So, I am cautiously in favour of a new drive. I am against using the existing rules, and I am against its lasting for a whole month. I wish to see us very heavily skewed towards good reviews of the older submissions. FiddleFaddle11:25, 2 September 2014 (UTC)
I agree with Timtrent but I harp back on our perenial issues: If a drive is designed to bring in new reviewers, how do we keep those reviewers when the drive is ended and there's no more points to be had and there isn't a leaderboard to score on. How do we keep our backlog managable after the backlog drive so that a new drive isn't an innevetable conclusion 2 weeks after the previous one finished? Hasteur (talk) 13:10, 2 September 2014 (UTC)
Agreed - brand new submissions are often super easy to review and shouldn't score points. I also agree that teh same reviewer rejecting something multiple times should only earn points once. However, I would leave the length at 1 month - that is the norm for backlog elimination drives of all types. No ideas on how to fix teh real problem (insufficent longterm reviewers). --ThaddeusB (talk) 15:34, 2 September 2014 (UTC)
I agree that a backlog drive should focus on backlog otherwise we should call it a surge or something. I suggest points could be awarded based on article-days: You get a point for every day an article you review has been awaiting review. If we stop giving low-quality submissions immediate attention, I believe our backlog problem may solve itself. ~KvnG15:59, 2 September 2014 (UTC)
I think it would also be useful to stop measuring our backlog in terms of number of articles. It is no problem to have thousands of articles waiting for review as long as each individual submission gets reviewed within a reasonable time. What matters to submitters is how long it takes for a review to happen, not how many other articles are awaiting review. Quick failing a submission does not seem to encourage the author to take time to make significant improvement to a submission before resubmitting. ~KvnG16:11, 2 September 2014 (UTC)
I'm going to respond to Hasteur's points about reviewer retention w.r.t. drives and leave the decision to active members. I originally joined the project (AfC, to be clear) because I was attracted by its premise – helping out newbies and improving the encyclopaedia. I accepted a couple of articles and declined some others. Soon after that I noticed and joined the drive, where for a whole month I focused my wiki activity on it, because I had become focused on the barnstar. After failing many poor drafts, including (I confess) many new ones, and passing only a few – since they were few and hard to find and took longer for the same reward – I became bonked and am now around only at Redirects and Categories for Creation (so please nobody take me off the script list).
The point is that AfC can be a very unrewarding job. This only increases my respect for those who put so much effort into it and make it at least somewhat successful. But to keep people, a key step is to increase the draft quality by improving the creation workflow for submitters. I recall that some users have proposals for such, but none were implemented.
Somehow we need to teach newbies how proper Wikipedia articles work and get them to even a rough approximation of that standard. That will improve the experience of both reviewers and submitters. If we could even reliably convince spammers not to submit, that would be a good step.
I mean no disrespect at all to you good people. These issues have been raised before and I believe addressing them is a prerequisite to a properly functional AfC. Little ideas: would a big red(?) editnotice warning against WP:NOT and copyright violations help cut the rate of utterly ineligible articles? BethNaught (talk) 16:33, 2 September 2014 (UTC)
"If we could even reliably convince spammers not to submit, that would be a good step." - this is probably the least likely improvement to actually happen. If someone is intent on promoting their business (or whatever), a notice saying it is unlikely to be accepted won't stop them. At "best", they will go straight to mainspace instead of AfC. Effort at improving the process would be better spent trying to get good faith people to improve their initial attempt. --ThaddeusB (talk) 18:28, 2 September 2014 (UTC)
Oppose any backlog drives until everything is fixed with AfC to Hasteur's satisfaction. The goal of a backlog drives isn't to bring in new reviewers, it is simply to take the number of pending submissions back into a 3-digit range from a 4-digit range. Until we have enough reviewers to keep it there, there is no reason to do a BLD. — {{U|Technical 13}} (e • t • c)12:13, 3 September 2014 (UTC)
Oppose for now, but I'll explain the alternative. I've been steadily categorising drafts into projects, and if we can all give that a go (which is simply a matter of going onto a draft talk page, which probably won't exist and adding an appropriate WikiProject template on it), then we should be able to gather statistics on what topic new users like creating articles. From that, we can weigh up supply and demand and do a backlog drive on that - eg: Drive this month is to take the 100 drafts tagged for Wikipedia:WikiProject Classical music and get them all to C class. Ritchie333(talk)(cont)12:40, 3 September 2014 (UTC)
I can save you some time: The top two categories are most certainly biographies (of living persons) and companies. Categorizing submissions is still useful because one of our ideas for permanently addressing backlog is to solicit help from wikiprojects. I don't see how that immediately connects with backlogs here though. ~KvnG15:19, 3 September 2014 (UTC)
I think it will psychologically help - would you rather deal with a backlog of 3,000 items on possibly anything, or you deal with a backlog of 100 albums, a backlog of 50 football players, and a backlog of 300 biographies, with specific reviewers on each one? Ritchie333(talk)(cont)15:25, 3 September 2014 (UTC)
The answer is that it depends on the person. As a generalist I run away from some classes of draft. Music is one I have a blindspot over. I have no issue with enjoying seeing 4,000 drop to 3,000 and then 2,000, but would find it hard to be asked to improve even a dozen articles on football.
If the draft status shows up in the active project lists from the work you've been doing, though, that might encourage some of the participants to come and play. I think that's your guiding principle, isn't it? FiddleFaddle16:40, 3 September 2014 (UTC)
Just to make the point again...
I just systematically scanned all of the 'Very Old' submissions with Earwig's tool... I didn't keep exact numbers or anything, but it appears that somewhere between 10%-15% so submissions that get to that point are still copyright violations. This is bad...please remember to scan them. Reventtalk17:30, 3 September 2014 (UTC)
What was the URL/string that you used? I might take a look at slapping together a simple automation to bulk submit anything in the 3 weeks old or older to Earwig's tool to get a evaluation of it's "Copyright Violation"-ness and write to a wiki page the evaluation so as to let editors who have free time sort through the highest offenders and speedy them under CV rules. Hasteur (talk) 19:12, 3 September 2014 (UTC)
We don't want to be running too many queries (It costs the WMF 0.8 cents for every request) and if we can handle the ones that get up to 3 weeks old, that's going to solve most problems. I'l also look at leaving a configurable list of categories to scan so that we can work our way down to 7 days eventually. The idea I have for the publically accessable list is to run the query out to the tool, get back the percentage and CV/Not CV counts and then place them into a page list inside hasteurbot's userspace with a sortable wikitable so that we can knock off the most offending ones first. I need to run the idea by Earwig and the Bot Approval Group to verify that I am allowed to do something like this (since it'll be a great many edits to the bot's own userspace). Hasteur (talk) 20:39, 3 September 2014 (UTC)
I could be wrong, but my understanding is that the 'rules' for the Yahoo BOSS search tool that Earwig uses is that it's not allowed to use it for automated queries. Reventtalk11:47, 4 September 2014 (UTC)
The tool has the option of skipping the search and just checking for violations based on links included in the submission. The non-search option could probably be run liberally. ~KvnG17:17, 4 September 2014 (UTC)
This means that, unless all of us take a good few each, we are heading for a major new editor dissatisfaction issue. I know a number of us are doing our best. Knocking 10 each per day of the list would be a decent start. FiddleFaddle10:03, 4 September 2014 (UTC)
I've done 10, which was much easier after doing the project / categorisation work, since I could easily pick a bunch of musician / band / album articles off the list. I'm not sure about ten every day, maybe five would be reasonable for a large amount of people, which leads me onto a humorous userbox.... Ritchie333(talk)(cont)11:38, 4 September 2014 (UTC)
Shoot for the stars. If you miss you may still hit the moon! Seriously, five is pleasantly acceptable, 10 is highly desirable, more is wonderful. We have to knock the oldest items off the list. Sadly I am finding that many are things that have not even been reviewed once. Even more sdaly I am finding it very hard to find drafts I can accept. FiddleFaddle11:48, 4 September 2014 (UTC)
FYI according to the list of backlog drives, they seem to have taken place every 3 months or so, so perhaps it is time for a new one. :)--Coin945 (talk) 14:11, 4 September 2014 (UTC)
You're on the list of AfC participants, so you should have access. Go to Preferences / Gadgets and ensure "Yet Another AFC Helper Script" is checked. You should then get the review option on drafts. Ritchie333(talk)(cont)15:59, 4 September 2014 (UTC)
It's not particularly obvious that you'd see the Review option under your "More" menu, only when you're on a draft page that has an AFC template on it. Roger (Dodger67) (talk) 16:21, 4 September 2014 (UTC)
I use quiet, calm determination. And I find they are all pretty much the same. Some of the most amusing are "performance coaches", who believe their own publicity. Just decline their puffery with care, ensuring your rationale is valid, and move quietly on. FiddleFaddle08:21, 5 September 2014 (UTC)
Coin945, take care that you do not accidentally blank drafts that should not be blanked - as you did at Draft:South Durban Community Environmental Alliance. The only reason for blanking a draft is if it consists entirely of a copyright violation, or an attack on someone or something or slander. When a draft is only partially a copyvio you remove only the offending part. So take a look at the checkboxes before you hit that button. Roger (Dodger67) (talk) 12:42, 5 September 2014 (UTC)
Is it not true that the only way to remove an article from the backlog is to clear the submission? As I am reviewing the really old ones, I think it is fair to assume that the creators have had long enough to copyedit their submission so it is as perfect as it is ever going to get. So either I will accept it into Wikipedia, or clear it.--Coin945 (talk) 13:04, 5 September 2014 (UTC)
Many of Coin945's reviews included incorrect blanking - it's really important that they be restored asap. If the submitter reads the decline message and goes looking for their draft it would be really confusing and unfair to arrive at a page that has been blanked for no good reason. Roger (Dodger67) (talk) 16:23, 5 September 2014 (UTC)
Actually User:Redrose64, if a draft is in the pending review pile it by definition cannot be eligible for G13 - our backlog is not more than six months! Tagging stale drafts is not part of the review workflow at all - there's a bot for that job. Roger (Dodger67) (talk) 16:36, 5 September 2014 (UTC)
Yes indeed, if it's been declined multiple times for the same reason (usually notability because editing cannot make a non notable topic become notable but other problems can be fixed by editing) and the submitter is simply not getting the message and keeps resubmitting, then MFD can be used to get rid of it. Roger (Dodger67) (talk) 16:57, 5 September 2014 (UTC)
Are submission accepts based on article potential or article current state? With the backlog I have been going with the former.--Coin945 (talk) 17:13, 5 September 2014 (UTC)
We want to accept any reasonable article on demonstrated notable topics. Basically If it is not a WP:COPYVIO or has a WP:BLP issue and abides by the WP:GOLDEN RULE, you should accept. You are, of course, always welcome to make improvements before accepting (e.g. delete promotional material, tag issues with copy editing, etc.). ~KvnG19:53, 5 September 2014 (UTC)
An example of what was, for me, a borderline decision is documented at Talk:Beer in Edinburgh. I accepted the draft with concerns, am unable to improve it myself, and have taken the view that main namespace is most assuredly worth a try. I am content to be correct or incorrect. Sometimes it is worth a gamble. FiddleFaddle21:52, 5 September 2014 (UTC)
There is a big gray area and each of us has our own way of negotiating that. The overall directive is that an accepted AfC submission WP:LIKELY survives WP:AFD. If you don't know what that means, I encourage you to weigh in on some AfD discussions and get a feel for the odds there. ~KvnG02:21, 6 September 2014 (UTC)
Draft talk: pages - a problem
This came to my attention via Gryllida who, quite reasonably and wisely, is using the Draft talk: pages to have solid conversations with authors in order to improve their submissions. I see this as an excellent idea, hampered by our own scripts and their mixed abilities to migrate the Draft talk: pages when a draft is accepted.
I've engaged them in a discussion over our scripts and the issues here to make them aware of a potential issiue in the future. Their comment that it is effectively someone else's problem is perfectly reasonable. We are that 'someone else' and we can't deal with the problem unless we know about it.
To be clear, I am recommending strongly that our scripts and their behaviour ensure that the Draft talk: page is migrated, not that the use of that page is somehow curtailed. I am in no way criticising Gryllida. Their dialogue concept is excellent.
Wow, I had no idea that didn't happen. I'm using Talk pages too (often for dumping content that's not useless but doesn't belong for now). Hope somebody can get to this! Jodi.a.schneider (talk) 23:32, 7 September 2014 (UTC)
It seems to be a legacy issue from when we used WT (only) not D and DT, and, as far as I know, the production script has not embraced DT, just D. FiddleFaddle23:54, 7 September 2014 (UTC)
Yeah, hopefully we can all start watching RC (Draft talk) instead of the help desk and talk pages of each-other. --Gryllida (talk) 09:56, 8 Septembr 2014 (UTC)
I can't believe I'm reading this thread - to have a dedicated talk page for each submission was 50% of the whole reason the Draft namespace was created in the first place, apart from the other advantages a proper namespace affords, such as the live feed that everyone is so reluctant to discuss - just for starters.
A spectre is haunting Wikipedia — the spectre of outright closure for AfC, an increasing sentiment that I tried hard to stifle last month in London. There are no alternatives to AfC; we (or perhaps only I) certainly don't want all new creations of the AfC kind being dumped on the already overloaded, undermanned/womaned, and incorrectly used NPP feed. For those who missed it, it's time to read this week's Signpost article about AfC, especially the reader comments. Of course, if we could get more NPPers of the right calibre, maybe I would join DGG's camp. KudpungMobile (talk) 11:04, 9 September 2014 (UTC)
As I mentioned above, it would be nice if the script could provide an option to linking drafts to projects, even those you don't plan to review. It takes much less effort to categorise a draft than review it, and can hopefully attract the attention of someone with subject knowledge. I'm doing a bunch of drafts, but I can't possibly do them all. Ritchie333(talk)(cont)13:04, 9 September 2014 (UTC)
Wow. I'm so discouraged by all this, because this is exactly what I've been saying right from the start, and everyone ignored me. Now, it seems many others are seeing the problems I said were going to become a major problem from the start. I'm no longer interested in working to fix the system that is now so badly broken by pushing this whole draft namespace thing before all the pieces where properly in place, and I think the whole thing should just be dumped in my opinion and replaced with a completely new system. Good luck. !!!!— Preceding unsigned comment added by Technical 13 (talk • contribs)
Yes, I would love to get AfC shut down entirely, and the sooner the better. Some of its features can possibly be migrated to NPP, but we should consider very carefully about each one, because I think that the value of many of them is either zero or negative. (We will still need a draft space where people can work on material not ready for mainspace, but I have not even tried to figure out what a workflow for it would be.) I think Kudpung is wrong about the staffing problem--presumably all the people who now work on AfC would migrate to its replacement, the upgraded NPP. We are much more likely to keep up with the queue of incoming material if there is only one queue. (Indeed, one reason for the present staffing problem at NPP is that we now have to staff both AfC and NPP--I used to do quite a lot of NPP, but now I do almost nothing at WP except try to rescue articles from AfC before they get deleted.) As I commented at the Signpost, the problem of totally inappropriate material getting indexed on Google could be solved by placing noindex on articles submitted by new editors for the first few hours or until patrolled. DGG ( talk ) 19:05, 13 September 2014 (UTC)
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.
Most urgent support ever. Talk pages are being left behind and we are creating a mess. And the old script needs to be deleted or redirected for those who have it imported in their personal JS. --Gryllida (talk) 10:08, 13 September 2014 (UTC)
Full support. I didn't even know about AFCHRW until a few weeks after I started reviewing, and another month flyer that before I realized I wasn't actually running AFCHRW. Cheers, Thanks, L235-TalkPing when replying14:36, 13 September 2014 (UTC)
Support. At this stage of development, it appears to have all the essential functions (a few minor ones are missing, such as the checkboxes for requesting an infobox or picture,and for adding text to the Talk p, or at the top of the accepted article). Of course, neither have some necessary functions that have been requested many times; the most critical are (1)The ability to select multiple reasons--if Twinkle can do it, this script should be able to also. (2). The ability to preview the template being placed, and to modify it--many WP procedures have this option, so it should be possible here also. (3).Inclusion of the additional comments or custom reason on the user's talk page--it only gives the prebuilt reasons, selected by the incredibly absurd kluge of copying the entire template for all possible decline reasons onto the talk p., and selecting the proper one. (4).An option for automatically opening the users talk page for additional comments--at present I do this by quickly selecting that page when it momentarily appears among the steps for declining. DGG ( talk ) 20:04, 13 September 2014 (UTC)
Support. Though apparently I am using the old script quite happily (I was unaware of these discussions and I usually switch of at the sight of lengthy discussions about script programming). If it is more efficient and gives clearer results I can't see a downside. Sionk (talk) 22:48, 14 September 2014 (UTC)
SionkHerd behavior is common, but I wouldn't like it to slip without clear understanding here. Do you acknowledge that draft talk pages should not be left behind when approving, and that correcting the unmaintained script is a wrong way to approach this? --Gryllida (talk) 23:25, 14 September 2014 (UTC)
SionkLike you can see some people use these talk pages. Would you consider their concern, along with the "unmaintained" status of the old script, sufficient for removing it from production? --Gryllida (talk) 01:19, 16 September 2014 (UTC)
I'm not sure what the sub-text of this interrogation is. I was asked to give my opinion on this and I've given it. If there are wider issues to be considered in this poll, maybe they should be spelled out in the opening question. Sionk (talk) 10:18, 16 September 2014 (UTC)
Support having everyone switch to the rewrite, but not actual removal of the other. I've been using Rewrite for months and haven't found a bug to report for some time, and it is needed for moving the Draft talk pages. I don't see the necessity of actually getting rid of the old script, if it still is needed for FFU, just asking everyone who doesn't work on that to uninstall the old one so that draft talk pages don't get left behind accidentally, and change any instructions to point new participants to the rewrite script. Because the AfC reviewing is so important, it's also good to have a mostly functional backup script in existence in case sometime in the future the rewrite should be non-functional for some reason. (Look what happened to Reflinks). —Anne Delong (talk) 12:33, 17 September 2014 (UTC)
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.
Why are we having another poll on this? It was already unanimously approved by project members pending addition of it handlinb WP:AFC/R and WP:FFU. — {{U|Technical 13}} (e • t • c)15:44, 13 September 2014 (UTC)
If you'd like to ask a sysop to delete or redirect old script page to new script page (or convert it to a redirect to a brief wiki page about why the switch is necessary and how to do it), go ahead. I was going to do that, but then saw this poll and figured it's worthwhile to complete it and request then. --Gryllida (talk) 02:37, 14 September 2014 (UTC)
If someone will explain what technically needs to be done to make the new script "live" I will do it - no need to keep this straw poll open I think. — Martin (MSGJ · talk) 11:02, 15 September 2014 (UTC)
You want to make 2834 users have to change their settings to use the new version? That sounds very inefficient! It might be nice if there was some alert that the users will see when they use the new version, but otherwise I expect they'll realize fairly quickly that something has changed. — Martin (MSGJ · talk) 11:01, 16 September 2014 (UTC)
Are you saying the old script is the only means to process FFU? Please write what actionable action can be taken to leave it working there, but not for draft reviews. Gryllida (talk) 00:10, 17 September 2014 (UTC)
@Gryllida: For those using FFU, they can manually install the script into their common/js file, and use it on the FFU page (as I have done). One feature used by a few that is easily reinstalled should not hold back fixes for the many. User:Legoktm may also be able to advise us on how to implement this, as T13 seems to want to hold it up for a bit. --Mdann52talk to me!07:31, 17 September 2014 (UTC)
Done (although I used a subpage of the current page to keep things tidier). It seems to be working for me, although you may have to clear your cache. — Martin (MSGJ · talk) 19:58, 24 September 2014 (UTC)
Less automated than ever
FYI User:Gryllida/draft/under-review appears to be by far smarter than the "fully-automated" helper-rewrite and helper tools. Augh. I reviewed around a handful of articles thanks to simply that — not having to work around the things these helper scripts lock me down to.
Hi, I suggest we have a guide for submitters when creating their article, perhaps a checklist. I think too many submitters submit their pages without knowing the proper criteria or what is expected in their articles. There's WP:YFA, but I don't think many submitters read that, and we need something more prominent (perhaps by placing a checklist on the not submitted for review template). Thoughts? Darylgolden(talk)10:47, 8 September 2014 (UTC)
How about a script/bot that sees new drafts and places a welcome (which they will also not read) on their talk pages that is tailored to the draft/submit/review/edit process? FiddleFaddle10:55, 8 September 2014 (UTC)
Why not simply follow some of the other discussions that are already pleading for the n'th time for a proper landing page for first-time article creators? The WMF started to create one just over two years ago but because the community couldn't be bothered to pressure them into finishing it or participate in its development, the Foundation let it flounder. What's being suggested in good faith above is simply just another set of palliatives. KudpungMobile (talk) 09:43, 9 September 2014 (UTC)
Darylgolden - check out the Article Wizard - it's a useful framework for discussing anything like this.
Gryllida, the WMF has everything to do with it, but you are probably not up to speed with all the developments over the past two years - not all discussions about AfC take place on this talk page, and indeed many of them are on the WikiMedia/MedWiki sites. If you are a sufficiently experienced user, I would imagine you should be able to answer the second issue intuitively yourself.
However, for the benefit of those who have joined AfC since all theother developments and who may not be aware of what's going on behind the scenes and in real life meetings, I'll be posting a compete set of links (again) as soon as I get back to my home computer. KudpungMobile (talk) 09:37, 12 September 2014 (UTC)
I'm aware of some WMF developments (Flow, Echo, VisualEditor, Content Translation, edit suggestions, and a welcome tool from their Growth tool which I don't know how to test without registering a second account in production here). The second question — the question of describing what a landing page does and where it appears — is an interesting question. I would be interested to know, actually. --Gryllida (talk) 10:39, 12 September 2014 (UTC)
Hello fellow AFC members. I'm not in AFC as of right now, as I do not meet the requirement of 500 mainspace edits. However, I'd like to proprose an "AFC Cup" sort of like the GA Cup starting on October 1st which you can find here. Do you think it could reduce the backlog? Cheers! Brandon (MrWooHoo) • Talk to Brandon!22:32, 13 September 2014 (UTC)
Hi Brandon. It may step up the productivity of the regular reviewers and it may attract other editors to the task. A trophy may enhance the recipient's sense of being part of Wikipedia and encourage their continued participation. It might also invite quicker, less accurate, and more superficial rewiewing. It could attract viewers who despite meeting the very low numeric threshold (500 edits/90 days) may not meet the rest of the criteria. KudpungMobile (talk) 02:10, 14 September 2014 (UTC)
