Last modified: 2013-01-31 15:38:02 UTC
There was recently a proposal on enwiki for disallowing non-autoconfirmed users from creating new articles. The proposal was widely endorsed, see http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)/Proposal_to_require_autoconfirmed_status_in_order_to_create_articles It was also mandated that this change should first be implemented as a temporary trial. The appropriate length of this trial was decided to be 6 months. See http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)/Proposal_to_require_autoconfirmed_status_in_order_to_create_articles/Trial_duration So, what we're looking for is a dev to tweak the code for enwiki such that non-autoconfirmed users can no longer: - create new pages (except in their own user namespace) - move pages from their user namespace to any other namespace If a non-autoconfirmed user tries to create a new article, they should be presented with the MW interface message at [[en:MediaWiki:Noautocreatetext]]. (If that page doesn't exist yet, it should be created shortly).
Call me dumb, but don't see any strong consensus here. If we simply sum the number of people supporting and opposing this change in principle, it will be something closer to 50/50. Also, lots of people opined on the need in an article creation wizard in software proper, as opposed to wiki pages. Can this possibility be seriously discussed before making such serious step?
I don't think this is the time or the place to second-guess the way the proposal was closed by an experienced admin. Note that over 500 editors participated, and the closing admin notes that "In this broadly attended discussion, more than two-thirds of those expressing a clear 'support' or 'oppose' opinion supported the proposal to limit article creation to autoconfirmed editors, either as a trial or on a permanent basis." No one has disputed the way this proposal was closed (and bugzilla is certainly not the place to do so). There is very strong consensus for this trial. As for a software version of an article creation wizard, that's a great idea but completely unrelated to this trial; linking the two is unnecessary and inappropriate. While this is a serious step, keep in mind it is only a trial. The trial will last for 6 months, and then this change will be reversed for 30 days while a discussion ensues on whether to make the changes permanent or to abandon the idea. Many editors have planned and worked for months to organize, propose and implement this change. I (and they) would be highly disappointed if it got hijacked on bugzilla, at the very last step of implementation.
The right way to deal with this is to cut to the root of the problem: we throw brand-new potential editors directly into shark-infested waters, then yell at them for splashing at the sharks. :) I agree with the basic concern -- putting newbies right into that environment so easily often ends up harming everyone -- but I don't think it would be ideal to simply cut off new article creation without actually providing a safe place for them to go instead. This needs to be paired with a *really good user-friendly way* for new accounts to create provisional articles, have them reviewed, get mentored by real people, and get their articles moved into real article space (or at least end up finding something better to do in a less confrontational way than a scary template and speedy deletion). I would recommend at least a serious beefing up of the requests for article creation pages before trying this; a newbie attempting to create a new article definitely needs to be shepherded through some checks, and should end up with the opportunity to at least create a page -- even if it's in a sandbox area. (In the future, please consider actually reaching out to developers for feedback as well before the final stages!)
(In reply to comment #3) > I would recommend at least a serious beefing up of the requests for article > creation pages before trying this; a newbie attempting to create a new article > definitely needs to be shepherded through some checks, and should end up with > the opportunity to at least create a page -- even if it's in a sandbox area. Can you define "beefing up"? The current en:WP:Articles_for_Creation and en:WP:Article_wizard have existed for quite some time and, in my opinion, do a good job of shepherding new users through the process of creating a new article. In addition, the error page which will be displayed to the user when they try to create a new article will give them clear instructions on how to get their article created despite being non-autoconfirmed: 1. It will direct them straight to Articles for Creation with instructions on how to use the Article Wizard to create a new article and have experienced editors review it. This process has worked for IPs creating new articles for years. 2. It will also provide a link to start the article in their userspace, with clear directions on how to get the attention of an editor to review the article and move it into mainspace for them when they're done. Or, they can just wait 4 days and make 10 edits, which is a very low bar to achieve. Can you identify the specific deficiencies in the current Articles for Creation and Article Wizard systems which you believe need to be "beefed up"?
Overall, I think we're thinking too hard about this. We're trying to figure out all of the problems that this change might cause and fix them beforehand, when in fact one of the major purposes of this trial is to actually identify what problems are caused (if any), what the nature of those problems are, and what the most effective way would be to fix them. If we're just blindly guessing that problems will be created at [[en:WP:AFC]] and vaguely insisting that we need to "beef up" something before the trial starts, then we might be implementing non-ideal solutions to non-existent problems. I think a far better idea is to actually implement the trial for a limited amount of time, collect some real data about its effects, and implement the most effective fixes to solve any problems caused.
Can someone explain to me how things work here when editors need to interface with the developers to make a change? We were hoping to just clearly explain what we need, point to the successful proposal which shows community consensus for a trial of the change, and get a dev to flip the user-rights switch for us. We were not aware that the entire concept was subject to another round of re-litigation by the developers at the 11th hour once the request is made on bugzilla. In particular, I'm concerned that these bugzilla discussions are not visible to any of the hundreds of editors who participated in the actual request for comments on enwiki. If there are technical issues with making this change, please let us know and we will work with you to resolve them. If you have editorial concerns about the change, then my feeling is that those concerns should have been voiced at the proposal, which ran for nearly 2 months and was widely advertised all over the village pump and centralized discussion areas. I don't want to come off as hostile and I don't want to dismiss anyone's legitimate concerns, but I feel like the comments being made here are essentially editorial comments by editors who missed the original proposal, and I find these comments to be out of place in this venue. Please let me know if my concerns are unfounded, or if this is the status quo here. Many editors have been planning the details of this trial for close to 6 months and are itching to see it get underway.
I'm with Brion on this one. I'm also wondering if the workflow we have here is sufficient and works as well as we think it does; that is, will the people who are now prohibited from creating a page really submit through the Articles for Creation process, or will they become discouraged and give up? I think there needs to be a very clear process for submitting articles and there needs to be a really good way of measuring the success/failure of such a trial. Disallowing anonymous page creation was a trial, without any means to gauge the results. While we're at least putting a 6 month cap on this...I really don't want us to fall down the slippery slope of rejecting more user contributions and driving more editors away because we never can decide if the trial was a good idea or not.
I have a few comments and a question. First the comments: I want to put things in perspective. I did an analysis of all new articles created from January-May 2011 (see [[en:User:Snottywong/Article creation stats]]). The analysis shows that nearly three-quarters of articles created by non-autoconfirmed users get deleted. Compare this to autoconfirmed users, where about 18% of new articles get deleted. If we extrapolate this out, it means that non-autoconfirmed users create about 191 articles per day (which don't eventually get deleted), whereas autoconfirmed users create about 2,272 articles per day (which don't eventually get deleted). My point in laying all these stats on you is this: even if this trial was a complete and utter failure, and it ended up causing 100% of non-autoconfirmed users who want to create a new article to give up and not try [[en:WP:AFC]] or make a userspace draft or wait 4 days or whatever... the worst that would happen is that the creation rate of decent new articles would temporarily decline by 8% for 6 months. And that's an extremely unlikely, absolute worst case scenario. Of course, there are other factors like attracting less new editors and such, but I just wanted to put this entire trial into perspective; it's not THAT big of a change. Also, I still haven't seen any specific comments about what is broken about the current Articles for Creation / Article Wizard system. Anonymous editors use this system quite regularly; it's not unusual to see 100 new articles proposed via AFC in a single day. If anyone can identify what specifically needs to be fixed with this system, then maybe we can address it. I believe it's a well-tuned system that is working just fine. We may want to recruit some more participants to review new articles when the trial is implemented, but apart from that I don't see much need for improvement. And now for my question: Where do we go from here? We have a proposal which ran for 2 months on enwiki where 300-400 editors supported the idea of this trial. And now that we're trying to implement it, we have a few devs with vague, non-specific criticism of the Articles for Creation system, who apparently are hesitant/unwilling to implement the trial. How do we resolve this? What do we need to do to get this trial implemented?
(In reply to comment #7) > I'm with Brion on this one. I'm also wondering if the workflow we have here is > sufficient and works as well as we think it does; that is, will the people who > are now prohibited from creating a page really submit through the Articles for > Creation process, or will they become discouraged and give up? I think there > needs to be a very clear process for submitting articles and there needs to be > a really good way of measuring the success/failure of such a trial. > > Disallowing anonymous page creation was a trial, without any means to gauge the > results. While we're at least putting a 6 month cap on this...I really don't > want us to fall down the slippery slope of rejecting more user contributions > and driving more editors away because we never can decide if the trial was a > good idea or not. The specifics and pre-trial statistics have been provided for trial and post-trial comparison and discussion. The trial is to be switched off after a period of 6 months, with en.Wiki reverting to pre-trial usergroup status. Immediately following the revert, 30 days have been allocated for the evaluation and assessment of the trial, during which the gathered data will be compared. In the case of a result favourable to the adoption of the new user policy, the new policy will be implemented as a permanent feature. In the event of results that demonstrate that the trial has not achieved its goal, namely that of greatly reducing the creation of the vast number of inappropriate new pages with minimal loss of retention of potential new users and potential suitable new articles, the project will be abandoned and the trial will not, under he terms of the present consensus, be reconducted. Moreover, it was clearly expressed that any alternative methods for the creation of new pages that were mentioned in the RfC were not, and are not, part of the discussion nor part of the implementation of the trial. Nevertheless, in deference to some suggestions that were made during the RfC, provision has been made to accommodate the possibility of shortening the 4 day/10 edit waiting period by providing three options of quick access to 1. The article wizard, 2. Articles for creation, and 3. automated creation of a new page template similar to the wizard, but in user space. A review and a page move by an established editor would then enable these new articles to go live more quickly. Due to the near total collapse of the New Page Patrol system, this project and its research and discussion, which have culminated in the required consesuses, have been a priority issue since October 2010; A request has been made via Bugzilla to prepare the software implementation of a trial that has been approved by consensus following correct en.Wiki due process. Bugzilla is not the place to attempt either a stalling procedure or attempts to relitigate what has been decided by established process.
FYI - The proposed mediawiki interface page is still at [[en:User:Snottywong/MediaWiki:Noautocreatetext]]. It should probably be moved to [[en:MediaWiki:Noautocreatetext]] before the trial is implemented. I don't personally have access to perform this move.
(In reply to comment #10) > FYI - The proposed mediawiki interface page is still at > [[en:User:Snottywong/MediaWiki:Noautocreatetext]]. It should probably be moved > to [[en:MediaWiki:Noautocreatetext]] before the trial is implemented. I don't > personally have access to perform this move. I do.
(In reply to comment #11) > (In reply to comment #10) > > FYI - The proposed mediawiki interface page is still at > > [[en:User:Snottywong/MediaWiki:Noautocreatetext]]. It should probably be moved > > to [[en:MediaWiki:Noautocreatetext]] before the trial is implemented. I don't > > personally have access to perform this move. > > I do. Only admins and devs would, so that makes sense. Having the parts in place before implementing the trial makes the most sense, because we'll get better results from the outset that way. I can tell you that I'm getting thoroughly sick of sifting through the morass that is Special:NewPages, and I work the front to compensate for the fact that very few experienced editors besides me will even dare to work NPP at all, much less the front.
I don't think there is strong enough consensus for this. I also think it is something that will significantly and negatively impact the Foundation's goals of editor engagement. I think there are better ways to handle this problem than more warnings; this entire idea doesn't appear to have been thought through.
(In reply to comment #13) > I don't think there is strong enough consensus for this. > > I also think it is something that will significantly and negatively impact the > Foundation's goals of editor engagement. I think there are better ways to > handle this problem than more warnings; this entire idea doesn't appear to have > been thought through. I would direct your attention to Comment 2.
Note to shell users: This bug is controversial; please do not implement at this time.
Frankly, I'm appalled by the way this request has been handled. You seem to be more interested in the WMF's goals of editor engagement, and not interested at all in Wikipedia's core policy on consensus. Is this really the way Wikipedia works when you pull back the curtains? A proposal can get clear consensus from 300-400 editors, but then a couple of developers can trump that consensus because they don't like the idea? Do you believe that the editors who supported this proposal were not aware of the WMF's goals for editor engagement when they voted for it? Do you believe that you are smarter and/or know better than the editors who supported this idea? How did you come to the conclusion that the consensus for this proposal is "not strong enough"? How many more supporting votes would it have taken for the consensus to be "strong enough"? Discussing the political aspects of this trial on bugzilla is extraordinarily inappropriate, not only because the comments are not visible to most wiki users, but because the political aspects have already been discussed and decided by ordinary wiki editors. If the developers want to have their say in whether various proposals should be enacted, then they should participate on Wikipedia by frequently checking and contributing to the proposals and centralized discussions as they are happening, NOT by going on strike when the request finally gets to bugzilla for the final stage of implementation. I have contacted the WMF in the hopes that this request will be fulfilled in a timely manner, without a discussion on the political aspects of the request (which has already happened in a 2-month-long discussion on enwiki).
(In reply to comment #15) > Note to shell users: This bug is controversial; please do not implement at > this time. There's pretty clear consensus on-wiki for this, after spending some time skimming the RfC. @Snottywong: I'm not opposed to doing this from the technical perspective, and many of the comments here have addressed the concerned I had raised above (comment 7). But as Brandon points out in comment 13, this has the potential of being very contentious (not just within enwiki), so I want to make sure before proceeding. (In reply to comment #16) > Frankly, I'm appalled by the way this request has been handled. You seem to be > more interested in the WMF's goals of editor engagement, and not interested at > all in Wikipedia's core policy on consensus. Is this really the way Wikipedia > works when you pull back the curtains? A proposal can get clear consensus from > 300-400 editors, but then a couple of developers can trump that consensus > because they don't like the idea? Do you believe that the editors who > supported this proposal were not aware of the WMF's goals for editor engagement > when they voted for it? Do you believe that you are smarter and/or know better > than the editors who supported this idea? How did you come to the conclusion > that the consensus for this proposal is "not strong enough"? How many more > supporting votes would it have taken for the consensus to be "strong enough"? > It has nothing to do with being smarter or setting unusually high barriers to consensus. It's about /making sure/ the consensus is there and making sure that such a change doesn't fly under the radar. Neither Brion nor I have at any point said "NOWAY IS THIS HAPPENING," we just both want to make sure it's done slowly, carefully and correctly :) > I have contacted the WMF in the hopes that this request will be fulfilled in a > timely manner, without a discussion on the political aspects of the request > (which has already happened in a 2-month-long discussion on enwiki). Who did you contact, so I can also contact that person and we can get the ball rolling as needed?
(In reply to comment #17) > (In reply to comment #15) > > Note to shell users: This bug is controversial; please do not implement at > > this time. > There's pretty clear consensus on-wiki for this, after spending some time > skimming the RfC. > @Snottywong: I'm not opposed to doing this from the technical perspective, and > many of the comments here have addressed the concerned I had raised above > (comment 7). But as Brandon points out in comment 13, this has the potential of > being very contentious (not just within enwiki), so I want to make sure before > proceeding. > (In reply to comment #16) > > Frankly, I'm appalled by the way this request has been handled. You seem to be > > more interested in the WMF's goals of editor engagement, and not interested at > > all in Wikipedia's core policy on consensus. Is this really the way Wikipedia > > works when you pull back the curtains? A proposal can get clear consensus from > > 300-400 editors, but then a couple of developers can trump that consensus > > because they don't like the idea? Do you believe that the editors who > > supported this proposal were not aware of the WMF's goals for editor engagement > > when they voted for it? Do you believe that you are smarter and/or know better > > than the editors who supported this idea? How did you come to the conclusion > > that the consensus for this proposal is "not strong enough"? How many more > > supporting votes would it have taken for the consensus to be "strong enough"? > > > It has nothing to do with being smarter or setting unusually high barriers to > consensus. It's about /making sure/ the consensus is there and making sure that > such a change doesn't fly under the radar. Neither Brion nor I have at any > point said "NOWAY IS THIS HAPPENING," we just both want to make sure it's done > slowly, carefully and correctly :) > > I have contacted the WMF in the hopes that this request will be fulfilled in a > > timely manner, without a discussion on the political aspects of the request > > (which has already happened in a 2-month-long discussion on enwiki). > Who did you contact, so I can also contact that person and we can get the ball > rolling as needed? I believe he's referring to Philippe.
Wikipedia is indeed the encyclopedia anyone can edit. There has however, never been a policy that anyone can create new pages. If the trial delivers the expected results, it will solve a far greater number of perennial problems than simply that of over 1,000 pages per day (80% of all newpages) that have to be deleted through one process or another, and which are largely patrolled by a loose group of extremely inexperienced, and partly very young and/or non native speakers of English - NPP is already widely recognised as a broken process. I believe there is every urgent reason to implement this trial now without further delay. The consensus was reached by a debate involving around 500 users and a clear majority in favour, and based on examination of the problem rather than straight subjective 'support' or 'oppose' !voting. A further centrally publicised RfC on the actual terms of the trial has also received practically unanimous support. I realise by now that the WMF may not in favour of this new user right change, but they should accept a decision arrived at by the very kind of consensus that they insist is the way to get things done at Wikipedia. By questioning the authority of the self governing Wikipedia community, any devs who would refuse this request for a trial, will be rocking the very foundation of a pillar of Wikipedia policy. Furthermore, Brendon is apparently overstepping his authority in unilaterally forbidding this trial. Rather than protecting a perceived user right for anyone to create new spam, attack, autobio, and copyvio pages, ultimately such action will result in the loss to the project of mature, established users and administrators who dedicate their free time to striving for improvement in the quality of Wikipedia, and its credibility as a universal knowledge base.
My apologies. I asked Brandon to enter that response. This change is a contested change, and I wanted to ensure that the change wasn't made by any of our volunteer ops engineers before the change was discussed further. If you'd like to blame someone, blame me.
To fill up everyone's inboxes just that little bit more, I think it's worth rebutting the above inaccuracy: > Wikipedia is indeed the encyclopedia anyone can edit. There has however, never > been a policy that anyone can create new pages. Sorry, but this is just wrong. All users, anonymous and otherwise, used to be able to create articles. It was a right that was "temporarily" suspended after the Seigenthaler issue in 2006, pending the creation of a system that would let us review changes before they went live. The fact that said system - Flagged Revisions, created to return us to the status quo (that is, one in which anonymous users can create articles) - has run into difficulties with the community does not mean that the idea that it's settled policy that there's no policy that all users can create new pages. I worry that this throws more heat than light on the situation, but we can't go around making massive changes to the community interaction model whilst at the same time relaying false and damaging claims about our intent, which don't help anyone.
Just so that people realize this isn't a "easy flip of a switch" that some people have been talking about. The proposal is to turn off ARTICLE SPACE ONLY page creation. Currently this right does not exist and you can only control "talk page creation" (createtalk) and "every other page creation" (createpage). While I have my own serious concerns over the trial there is no doubt that it assumes new users will be able to create non article space pages such as User pages and so this can NOT be implemented (from a technical stand point) until a core mediawiki change is made to separate mainspace page creation rights.
(In reply to comment #22) > Just so that people realize this isn't a "easy flip of a switch" that some > people have been talking about. The proposal is to turn off ARTICLE SPACE ONLY > page creation. Currently this right does not exist and you can only control > "talk page creation" (createtalk) and "every other page creation" (createpage). > > While I have my own serious concerns over the trial there is no doubt that it > assumes new users will be able to create non article space pages such as User > pages and so this can NOT be implemented (from a technical stand point) until a > core mediawiki change is made to separate mainspace page creation rights. This can be done with a one-line hook, no changes in core are needed, I think.
(In reply to comment #16) > Frankly, I'm appalled by the way this request has been handled. You seem to be > more interested in the WMF's goals of editor engagement, and not interested at > all in Wikipedia's core policy on consensus. Is this really the way Wikipedia > works when you pull back the curtains? Come down off the Reichstag, please, and take off the spiderman outfit. Everyone here has the best interest of the projects at heart, and so can we all please just calm down and let us get our bearings here? We know this is a core change - see Comment 22 - and that it won't happen immediately. We also know there's some real dispute about whether it should happen at all. I understand that there's a poll that came to consensus, but we are in the midst of a push toward editor retention, and it seems those two must be reconciled. So let's take our time and work through this, okay? pb
(In reply to comment #23) > This can be done with a one-line hook, no changes in core are needed, I think. [[mw:Manual:Preventing_access#Restrict_page_creation_in_certain_namespaces]] seems to say that they would have to use an extension (which is beta and would need a thorough security review and make sure it can scale to our size) or a core change. That would be up to the developers however.
(In reply to comment #25) > (In reply to comment #23) > > > This can be done with a one-line hook, no changes in core are needed, I think. > > > [[mw:Manual:Preventing_access#Restrict_page_creation_in_certain_namespaces]] > seems to say that they would have to use an extension (which is beta and would > need a thorough security review and make sure it can scale to our size) or a > core change. That would be up to the developers however. Cough cough. $wgHooks['userCan'][] = 'efBlockNoobs'; function efBlockNoobs( &$title, &$user, $action, &$result ) { if ( $action = 'create' && $title->getNamespace() == NS_MAIN && $user->isNewbie() ) { $result = false; return wfMsg( 'noobs-go-away' ); } return true; } Cough.
(In reply to comment #24) > I understand that there's a poll that came to consensus, but we are in the > midst of a push toward editor retention, and it seems those two must be > reconciled. > > So let's take our time and work through this, okay? Is there any hard data which suggests that this trial will decrease new editor retention by a measurable amount? I'm not sure why this is a default assumption. For instance, recent research seems to indicate that new editors whose edits get reverted and whose new articles get deleted are more likely to leave (see the August 8th Signpost). If we delay new article creation by a few days, is it not possible that the experience gained by becoming autoconfirmed might actually improve the editor's chances of creating an article which does not get deleted, thus actually improving editor retention? I'm not saying there's any hard evidence either way, but I don't think it's fair to say that restricting article creation to autoconfirmed editors will definitely reduce new editor retention. I'm willing to slow down and work through this to get it implemented. Max seems to indicate above in comment 26 that the change is trivial. Please let us know what else needs to be worked through, and what the road map is for working through it.
(In reply to comment #27) > I'm not saying there's any hard evidence either way, but I don't think it's > fair to say that restricting article creation to autoconfirmed editors will > definitely reduce new editor retention. This is why we're not requesting a permanent change but instead just a temporary trial: so that we can find out exactly what happens and not just guess.
We have buckets and buckets of hard data that says this change will harm the encyclopedia. The fact that it was ignored by those who push for this change doesn't make it any less relevant or accurate. If you somehow missed it the previous fifty times we published it, I suppose you can find yourself a stack of links to it by reading the latest Signpost; it was a big topic at Wikimania. This change will damage (and possibly kill) the encyclopedia. It's sheer folly to even suggest it - EVEN AS A TRIAL. And what a lot of new page patrollers seem to miss is this: If the workload is so high, why are you so intent on eliminating the funnel of potential new patrollers? It's a weird form of self-harm going on here.
(In reply to comment #29) > We have buckets and buckets of hard data that says this change will harm the > encyclopedia. The fact that it was ignored by those who push for this change > doesn't make it any less relevant or accurate. If you somehow missed it the > previous fifty times we published it, I suppose you can find yourself a stack > of links to it by reading the latest Signpost; it was a big topic at Wikimania. Please provide a link showing actual hard data (i.e. non-theoretical proof and/or experimental evidence) which specifically shows that restricting non-autoconfirmed editors from creating new articles will create a significant decline in new editor retention, and/or damage (and possibly kill?!) the entire project. I sincerely doubt you can, since to my knowledge it's never been attempted before. Thus, why we would like to attempt it, so that we can base our beliefs on evidence rather than gut feelings. > And what a lot of new page patrollers seem to miss is this: If the workload is > so high, why are you so intent on eliminating the funnel of potential new > patrollers? Are you familiar with the actual hard statistical data which shows that nearly three-quarters of all articles created by non-autoconfirmed editors are deleted, most of which are deleted immediately? See comment 8 above. > It's a weird form of self-harm going on here. Are you suggesting that you think hundreds of editors have secretly banded together with the intent to harm Wikipedia by restricting non-autoconfirmed editors from creating new articles?
(In reply to comment #30) > Please provide a link showing actual hard data (i.e. non-theoretical proof > and/or experimental evidence) which specifically shows that restricting > non-autoconfirmed editors from creating new articles will create a significant > decline in new editor retention, and/or damage (and possibly kill?!) the entire > project. I sincerely doubt you can, since to my knowledge it's never been > attempted before. Thus, why we would like to attempt it, so that we can base > our beliefs on evidence rather than gut feelings. Look at that: on the Signpost, just like I said: http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2011-08-08/News_and_notes It does not take a genius IQ to extrapolate saying "no, you can't edit the encyclopedia" to new users will cause them to get disappointed and go away based on all of this. It's very, very fragile, this thing. I disagree that you can't base decisions on "gut feelings" in this case. I'm fairly certain that if I get stabbed it will hurt; I don't need someone to actually stab me to have actual data points to draw the conclusion. > > And what a lot of new page patrollers seem to miss is this: If the workload is > > so high, why are you so intent on eliminating the funnel of potential new > > patrollers? > > Are you familiar with the actual hard statistical data which shows that nearly > three-quarters of all articles created by non-autoconfirmed editors are > deleted, most of which are deleted immediately? See comment 8 above. Yes, I am familiar with that statistic (which is poorly understood, to my knowledge), and I don't think it supports what you think it does. I think it mostly supports that a lot of people are trigger-happy deletionists eager to ramp up their edit counts so that they can "make admin faster" more than it means that everyone in the world has Bad Faith. > > It's a weird form of self-harm going on here. > > Are you suggesting that you think hundreds of editors have secretly banded > together with the intent to harm Wikipedia by restricting non-autoconfirmed > editors from creating new articles? No, I'm suggesting that this change is myopic in scope and: a) Violates a resolution by the Board of Trustees, and b) Violates the spirit of the Five Pillars
(In reply to comment #6) > Can someone explain to me how things work here when editors need to interface > with the developers to make a change? We were hoping to just clearly explain > what we need, point to the successful proposal which shows community consensus > for a trial of the change, and get a dev to flip the user-rights switch for us. > We were not aware that the entire concept was subject to another round of > re-litigation by the developers at the 11th hour once the request is made on > bugzilla. In particular, I'm concerned that these bugzilla discussions are not > visible to any of the hundreds of editors who participated in the actual > request for comments on enwiki. In rare cases, the Wikimedia sysadmins act as Defenders of the Wiki. Occasionally a Wikimedia wiki will decide that it wants to implement a change that is technically feasible and that has consensus among the local community, but the change is still rejected by the system administrators. An old, classic example is the proposal to delete unused accounts from the English Wikipedia. It received substantial on-wiki support, but was flatly rejected by the system administrators (cf. [[Wikipedia talk:Delete unused username after 90 days]]). There are arguments for and against this type of guardianship. In the best case, it acts as a safeguard against the will of an often ill-informed majority. In the worst case, it eviscerates project autonomy in favor of a [[m:technocracy]]. In this particular case, there seems to be a great deal of unnecessary hyperbole from the Wikimedia Foundation/system administrator side. I don't find much of it to be helpful or substantiated. I'm re-adding the "shell" keyword to this bug. There isn't any technical reason that this change can't be implemented by a shell user right now. That's the standard for use of the keyword. Individual objections, from Wikimedia Foundation or others, don't affect this reality. As with so many other bugs, there's a likelihood that this bug will simply be left to rot. System administrators have never been above passive-aggressiveness. In this case, it's not some poor project with a half-dozen active users in a language that nobody speaks, though, it's the English Wikipedia. So I can't imagine trying to ignore this bug will go over well, for better or worse.
The bug is certainly not being ignored. In light of the current focus on new editor retention across all projects, as a focus for community, board and staff (not that those groups aren't overlapping), I agree that having other eyeballs on this bug is warranted, outside of those from en wiki who participated in the discussion on-wiki. I understand that's going to annoy folks who spoke up, voiced their opinion, and thought the matter was closed. Please be patient; this really is a Big Deal (tm), so let's try to get it right.
(In reply to comment #31) > > Please provide a link showing actual hard data (i.e. non-theoretical proof > > and/or experimental evidence) which specifically shows that restricting > > non-autoconfirmed editors from creating new articles will create a significant > > decline in new editor retention, and/or damage (and possibly kill?!) the entire > > project. I sincerely doubt you can, since to my knowledge it's never been > > attempted before. Thus, why we would like to attempt it, so that we can base > > our beliefs on evidence rather than gut feelings. > > Look at that: on the Signpost, just like I said: > > http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2011-08-08/News_and_notes > > It does not take a genius IQ to extrapolate saying "no, you can't edit the > encyclopedia" to new users will cause them to get disappointed and go away > based on all of this. It's very, very fragile, this thing. There is nothing in that signpost that is specifically about restricting non-autoconfirmed users from creating new articles. There is only an article about stats which imply that new users are more apt to leave the project if their first few edits are reverted or deleted. While that study doesn't seem to specifically include new articles getting deleted, I think it's logical to assume that this would count as a form of rejection. Indeed, in my own analysis of the first 5 months of this year, 60% of non-autoconfirmed users whose new article was deleted never made another edit to the project. That's nearly 10,000 new users per month who quit after their article was deleted. Only 4% of non-autoconfirmed users whose new article was deleted eventually became autoconfirmed. That is hard evidence based on statistics: new users who create articles that get deleted simply do not stick around. > I disagree that you can't base decisions on "gut feelings" in this case. I'm > fairly certain that if I get stabbed it will hurt; I don't need someone to > actually stab me to have actual data points to draw the conclusion. This is actually a far more complicated issue than you give it credit for. There really is no telling what this change would do for new editor retention. I'm hoping that it will improve new editor retention. There are a lot of new editors who come here just to create an article on something they think is missing, and then they leave. If those editors would be required to make a slightly larger investment in order to create that article, will most of them choose to abandon it, or will they go make the investment and perhaps in the process realize how rich of an experience Wikipedia is, and eventually become a long-term editor? Will that experience of becoming autoconfirmed force them to learn more about Wikipedia before they create that first article, upping the chances that their article doesn't get deleted, and therefore sparing them the initial rejection which might have caused them to leave? No one knows, and gut feelings certainly aren't helpful in predicting such a complicated situation. > Yes, I am familiar with that statistic (which is poorly understood, to my > knowledge), and I don't think it supports what you think it does. I think it > mostly supports that a lot of people are trigger-happy deletionists eager to > ramp up their edit counts so that they can "make admin faster" more than it > means that everyone in the world has Bad Faith. That statistic was never intended to prove that everyone in the world has bad faith. It was intended to show that the vast majority of articles created by brand new users are utter crap (and if you've ever done any new page patrolling, you'd be quite aware of this). It's extreme bad faith to say that the people who are deleting these articles are "trigger-happy deletionists" trying to game the system at the expense of new users. Seriously, that is ridiculous and you should be ashamed of making a comment like that which disparages the hard work of dozens of editors, particularly considering you're on the WMF staff. If it weren't for patrollers filtering out these terrible articles, Wikipedia would be a laughingstock by this point. > No, I'm suggesting that this change is myopic in scope and: > > a) Violates a resolution by the Board of Trustees, and > b) Violates the spirit of the Five Pillars I disagree on both points. There is no data which proves that this change will harm editor retention, and there is nothing in this trial which violates the five pillars. Wikipedia is the encyclopedia that anyone can edit, not necessarily the encyclopedia on which anyone can create new articles. I would suggest that your opinions are myopic, based on gut reactions rather than experimental data, and appear to be mired in stereotypes and bias (based on your bad-faith "trigger-happy deletionists" comment above). In any case, the community has clearly spoken, and re-arguing these points on bugzilla is not what I came here to do. I'm going to attempt to not argue the politics of this trial in this venue any further, and defer to the devs who are wiser than myself to ensure that this trial is correctly implemented. Feel free to email me if you'd like to discuss the politics of this trial further.
I'd also add that most experienced editors won't touch NPP because 1. it's like drinking out of the sewer of articles (to crib from Orangemike) and 2. you become a Wiki-burakumin; no one really likes you. New users don't like it when we tag their advertisements for deletion, and experienced editors who only see the few misfires (granted, with the newer NPPers it's more like several, but for someone like me not so much) accuse us of tearing newbies' heads off. The system we have now isn't as effective as we'd like it to be, ergo we want to try something else. I'm the one who got this whole thing started, and I was the one who wanted a trial so that, if it is every bit the disaster described above, we can pull back from the ledge. But I can say that, with the system now, I've come across things that would expose the WMF to lawsuits (one was particularly frightening, because most English-speakers wouldn't have known just how bad it was). Anyways, we won't know what the effects will be until implementation, so instead of Doomsday scenarios we should instead get the hard data and see what happens. And finally, Jimbo himself said that he was happy that the discussion's result came out of empirical evidence; I'd like to keep it on that track.
(In reply to comment #34) > That statistic was never intended to prove that everyone in the world has bad > faith. It was intended to show that the vast majority of articles created by > brand new users are utter crap (and if you've ever done any new page > patrolling, you'd be quite aware of this). It's extreme bad faith to say that > the people who are deleting these articles are "trigger-happy deletionists" > trying to game the system at the expense of new users. Seriously, that is > ridiculous and you should be ashamed of making a comment like that which > disparages the hard work of dozens of editors, particularly considering you're > on the WMF staff. If it weren't for patrollers filtering out these terrible > articles, Wikipedia would be a laughingstock by this point. > You know, in the old days of Wikipedia, crap articles caused people to edit, to improve them. People see stubs and poor quality articles, and that prompts them to edit. By deleting poor quality articles from newbies you kill off the newbies, and you kill off newbies that are willing to add information to poor quality articles. You can't expect every new article to be awesome. The current articles all started off as crap. Why don't we instead make a policy that marks "crap" articles as being poor quality, then funnel our efforts into make them good? Instead of deleting something, why don't you take a few minutes to make it better? It's the community that has the problem, not the newbies. This policy will simply reinforce the poor social norms that have formed within our own community. > I disagree on both points. There is no data which proves that this change will > harm editor retention, and there is nothing in this trial which violates the > five pillars. Wikipedia is the encyclopedia that anyone can edit, not > necessarily the encyclopedia on which anyone can create new articles. I would > suggest that your opinions are myopic, based on gut reactions rather than > experimental data, and appear to be mired in stereotypes and bias (based on > your bad-faith "trigger-happy deletionists" comment above). In any case, the > community has clearly spoken, and re-arguing these points on bugzilla is not > what I came here to do. I'm going to attempt to not argue the politics of this > trial in this venue any further, and defer to the devs who are wiser than > myself to ensure that this trial is correctly implemented. Feel free to email > me if you'd like to discuss the politics of this trial further. Creation is a form of change. Editing is simply the ability to change. Creation and editing are the exact same concept. We should be giving people more freedom to change over time, not less. You know, if we disabled editing for everyone except people who have been forced to recite by memory all of our policies word for word or restricted it to known good editors, we would have *way* less reverts for new editors, because we'd have no new editors. This policy is just one step towards turning Wikipedia into an encyclopedia only elitists can change.
(In reply to comment #34) > There is nothing in that signpost that is specifically about restricting > non-autoconfirmed users from creating new articles. There is only an article > about stats which imply that new users are more apt to leave the project if > their first few edits are reverted or deleted. While that study doesn't seem > to specifically include new articles getting deleted, I think it's logical to > assume that this would count as a form of rejection. Indeed, in my own > analysis of the first 5 months of this year, 60% of non-autoconfirmed users > whose new article was deleted never made another edit to the project. That's > nearly 10,000 new users per month who quit after their article was deleted. > Only 4% of non-autoconfirmed users whose new article was deleted eventually > became autoconfirmed. That is hard evidence based on statistics: new users > who create articles that get deleted simply do not stick around. Right. > This is actually a far more complicated issue than you give it credit for. > There really is no telling what this change would do for new editor retention. > I'm hoping that it will improve new editor retention. There are a lot of new > editors who come here just to create an article on something they think is > missing, and then they leave. If those editors would be required to make a > slightly larger investment in order to create that article, will most of them > choose to abandon it, or will they go make the investment and perhaps in the > process realize how rich of an experience Wikipedia is, and eventually become a > long-term editor? Will that experience of becoming autoconfirmed force them to > learn more about Wikipedia before they create that first article, upping the > chances that their article doesn't get deleted, and therefore sparing them the > initial rejection which might have caused them to leave? No one knows, and gut > feelings certainly aren't helpful in predicting such a complicated situation. I'd agree it's more complicated than made out to be here. Though...without targeted funneling of people to at least edit existing articles, I doubt hardly anyone will "learn more about Wikipedia before they create that first article". > That statistic was never intended to prove that everyone in the world has bad > faith. It was intended to show that the vast majority of articles created by > brand new users are utter crap (and if you've ever done any new page > patrolling, you'd be quite aware of this). It's extreme bad faith to say that > the people who are deleting these articles are "trigger-happy deletionists" > trying to game the system at the expense of new users. Seriously, that is > ridiculous and you should be ashamed of making a comment like that which > disparages the hard work of dozens of editors, particularly considering you're > on the WMF staff. If it weren't for patrollers filtering out these terrible > articles, Wikipedia would be a laughingstock by this point. > Yes, I've done NP patrol before...and it's pretty terrible. I've also made a few misfires early on too. Patrollers could definitely better orientation. It's also tempting to move quickly to manage the backlog, but speed increases mistakes like bad deletions or tagging. It would be *nice* if we could get newbies to help in the new page cleanup effort, but it's hard to "nutshell" our new page policies. Without that, newbie help could just make the mess worse (with copyvios, editorializing, and poor sources). Still, it seems like there has to be something better than a hard autoconfirmed restriction...that feels like totally "giving up". > > No, I'm suggesting that this change is myopic in scope and: > > > > a) Violates a resolution by the Board of Trustees, and > > b) Violates the spirit of the Five Pillars > > I disagree on both points. There is no data which proves that this change will > harm editor retention, and there is nothing in this trial which violates the > five pillars. Wikipedia is the encyclopedia that anyone can edit, not > necessarily the encyclopedia on which anyone can create new articles. IMO, this does seem to go against those principles pretty clearly. I don't think the "edit"/"create" distinction works here. "anyone can edit" didn't mean "edit" in the strictly idiosyncratic MediaWiki sense, or at least, I highly doubt that. > I would suggest that your opinions are myopic, based on gut reactions rather than > experimental data, and appear to be mired in stereotypes and bias (based on > your bad-faith "trigger-happy deletionists" comment above). In any case, the > community has clearly spoken, and re-arguing these points on bugzilla is not > what I came here to do. I'm going to attempt to not argue the politics of this > trial in this venue any further, and defer to the devs who are wiser than > myself to ensure that this trial is correctly implemented. Feel free to email > me if you'd like to discuss the politics of this trial further. I'd agree that we need not get into NP-patroller bashing, especially on a bug report.
My understanding was that there was a pretty large group discussion at Wikimania, and that documentation of that discussion is forthcoming (should be in the next week or so as people get back from post-Wikimania vacation). I wasn't there, so I'm a very poor candidate to speak to what was said there, but I'd like to ask that we hold off on any action on this until the notes from that discussion are posted. Thanks!
(In reply to comment #36) > (In reply to comment #34) > > That statistic was never intended to prove that everyone in the world has bad > > faith. It was intended to show that the vast majority of articles created by > > brand new users are utter crap (and if you've ever done any new page > > patrolling, you'd be quite aware of this). It's extreme bad faith to say that > > the people who are deleting these articles are "trigger-happy deletionists" > > trying to game the system at the expense of new users. Seriously, that is > > ridiculous and you should be ashamed of making a comment like that which > > disparages the hard work of dozens of editors, particularly considering you're > > on the WMF staff. If it weren't for patrollers filtering out these terrible > > articles, Wikipedia would be a laughingstock by this point. > > > > You know, in the old days of Wikipedia, crap articles caused people to edit, to > improve them. People see stubs and poor quality articles, and that prompts them > to edit. > > By deleting poor quality articles from newbies you kill off the newbies, and > you kill off newbies that are willing to add information to poor quality > articles. You can't expect every new article to be awesome. The current > articles all started off as crap. > > Why don't we instead make a policy that marks "crap" articles as being poor > quality, then funnel our efforts into make them good? Instead of deleting > something, why don't you take a few minutes to make it better? > > It's the community that has the problem, not the newbies. This policy will > simply reinforce the poor social norms that have formed within our own > community. > > > I disagree on both points. There is no data which proves that this change will > > harm editor retention, and there is nothing in this trial which violates the > > five pillars. Wikipedia is the encyclopedia that anyone can edit, not > > necessarily the encyclopedia on which anyone can create new articles. I would > > suggest that your opinions are myopic, based on gut reactions rather than > > experimental data, and appear to be mired in stereotypes and bias (based on > > your bad-faith "trigger-happy deletionists" comment above). In any case, the > > community has clearly spoken, and re-arguing these points on bugzilla is not > > what I came here to do. I'm going to attempt to not argue the politics of this > > trial in this venue any further, and defer to the devs who are wiser than > > myself to ensure that this trial is correctly implemented. Feel free to email > > me if you'd like to discuss the politics of this trial further. > > Creation is a form of change. Editing is simply the ability to change. Creation > and editing are the exact same concept. We should be giving people more freedom > to change over time, not less. > > You know, if we disabled editing for everyone except people who have been > forced to recite by memory all of our policies word for word or restricted it > to known good editors, we would have *way* less reverts for new editors, > because we'd have no new editors. > > This policy is just one step towards turning Wikipedia into an encyclopedia > only elitists can change. I'd advise you to read a little Han Feizi. His argument was that the Sage Kings of China did what was right for them 8 centuries ago (at the time), but that the kings of his day needed to do what was right for here and now, and that concept applies here. We can't delude ourselves into thinking our reputation will be improved by letting newbies pour heaps of crap on us and leaving. We should be driving away a large percentage of people, because a large percentage don't want to help us; vandals and SEO upstarts are a huge percentage of our "new editors". I myself joined only in March 2010; I didn't join because I saw articles that looked like shit, but because I was so impressed with the quality of some articles that I figured it'd be neat just to fix a few typos and do a little bit of work. Over a year later, I'm still here; I wouldn't have been affected by this change at all, because I didn't create my first article until January this year. Instead of resorting to the methods of 2001-2002, get with the times NOW. You won't know until you try.
(In reply to comment #39) > I myself joined only in March 2010; I didn't > join because I saw articles that looked like shit, but because I was so > impressed with the quality of some articles that I figured it'd be neat just to > fix a few typos and do a little bit of work. Over a year later, I'm still > here; I wouldn't have been affected by this change at all, because I didn't > create my first article until January this year. Instead of resorting to the > methods of 2001-2002, get with the times NOW. You won't know until you try. My first edit was to create a new article (in 2007). I had made some minor edits as an IP before that, correcting typos and such, but I was forced to register to create my article (i.e. Wikipedia is already not an encyclopedia where anyone can create an article). Had I been forced to wait 4 days and make 10 edits, I can say with confidence that it would not have deterred me. I had done my research and I knew that the article I wanted to create passed the notability bar and had plenty of verifiable sources. I was going to create it regardless of the hurdles I would have to jump through. On the other hand, if my plan was to create an article which consists of "My buddy John is cool, he likes bicycles and has red hair" then I probably wouldn't have bothered to wait the 4 days. My point is I agree with Blade (comment 39). We can do just fine without 72% of the articles that non-autonconfirmed users are creating currently. I can honestly say that had I been forced to become autoconfirmed first, I probably would have been annoyed, but only because I wouldn't have been warned ahead of time. If I had gotten plenty of warnings while editing as an IP that I would eventually need to become autoconfirmed before I'd be able to create new articles, then I probably would have registered a lot sooner and made my minor lurking edits as a registered editor. So perhaps one thing we should concentrate on is being more proactive about warning IP editors that not only will they need to register to create new articles, but they'll need to make 10 edits over 4 days while registered. Perhaps we can add this warning to [[Mediawiki:Nocreatetext]] and even the anonymous editnotice, so that every time an IP editor makes an edit, they're reminded of the restrictions on their editing and given an incentive to edit as a registered user (e.g. "Here are the added benefits of registering:"). The more advance notice we give anonymous editors will make it less of a surprise and make them less annoyed when they realize they need to become autoconfirmed.
FYI - I have started a work page for ideas on how to best implement this trial in such a way as to minimize the frustration caused to our new users. It can be found at [[WP:ACTRIAL]]. We would be thrilled to have developers contribute to the discussions, as several of the ideas will require developer resources to implement. (In reply to comment #3) > (In the future, please consider actually reaching out to developers for > feedback as well before the final stages!) Now's your chance! Cheers
To echo Snottywong in the comment above me, we'd love input from any or all of the devs at [[WP:ACTRIAL]]. Your suggestions are quite welcome.
Hi everyone, and thanks for your patience. As you can see from all the previous discussion on the bug, on-wiki, and on the mailing lists, there are some strong reservations about this proposal. As the closing statement of the Request for Comment on the trial noted, both sides on this issue believe that what they’re doing will lead to greater openness and constructive participation in Wikipedia. And, the Board has asked us all to work together to promote and increase the openness of Wikimedia projects. We understand the goals of the autoconfirmed trial as stated: - - - 1) This would reduce the workload on New Page Patrollers; 2) New users would be "bitten" less due to the resulting reduction in stress on the part of those most in contact with them; 3) New users are less likely to be disenchanted by their article being deleted 4) Autoconfirmed users with 10 edits to existing articles would enjoy an easier learning curve than trying to create an encyclopedic article with their first edit. http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)/Proposal_to_require_autoconfirmed_status_in_order_to_create_articles - - - Implicit in these goals are a desire to promote learning how to create a new article, a desire to reduce biting of new editors, and a desire to reduce the workload of new page patrollers. Not stated, but assumed, is a desire to maintain and increase the quality of Wikipedia articles. However, we believe that creating a restriction of this type is a strong a statement of exclusion, not inclusion, and that it will confuse and deter good faith editors. Instead of trying to address many different issues by means of a simple but potentially highly problematic permission change, we believe that in order to create a friendly, welcoming and understandable experience for new editors, we need to apply an iterative, multi-prong approach, including but not limited to: * simplifying the actual workflow of new article creation and reducing instruction creep * experimenting with alternative models to provide new users with safe spaces for new article development * connecting new users with experienced mentors faster. I’d like to invite the people who’ve commented on the bug and who have worked hard to think about our options to continue to do so on-wiki in collaboration with those of us at the Wikimedia Foundation. We’ve worked up a shortlist of ideas to significantly improve the process for creating articles on Wikipedia for everyone. Your thoughts are most welcome: http://www.mediawiki.org/wiki/ArticleCreationWorkflow I’m sure you’ll find some of the ideas in the proposed flow problematic, but please also tell us which parts make sense to you. Please look especially at the “Future Phases” section of the page, as we think it’ll take iteration to optimize across all variables we care about: getting more quality content, recruiting and retaining excellent contributors, and reducing new page patroller workload. Because this issue isn’t limited to the English Wikipedia, we’d like to ask you to comment on MediaWiki.org, where we will invite folks from other language editions to participate in the conversation as well. There are some very interesting experiences that we should learn from, including, for example, an experiment with article incubation in the Russian Wikipedia. Thanks for all your efforts to make Wikipedia better, and sorry for the long silence. We absolutely hope that we can move forward in partnership. WMF is prepared to invest effort (software development, design, research) to help get this right. We don’t have unlimited resources, but we can help :-). Let’s try to come up with the best experience for article creation that we can, to build a better encyclopedia and grow and nurture a healthy, diverse community. All the best, Erik
I will have more to say on this later, but what there would prevent us from working on that with, instead of despite, this idea?
(In reply to comment #43) > However, we believe that creating a restriction of this type is a strong a > statement of exclusion, not inclusion, and that it will confuse and deter good > faith editors. On what data are you basing this opinion? The specific way that new editors will respond to various interface changes is an extremely chaotic phenomenon, and it would be naive to believe that anyone could accurately predict the result of this change without any experimental data. Why is the WMF so resistant to implementing a brief trial so that we can base our opinions on facts rather than gut reactions? Even if we implemented the trial for a shorter period of time than 6 months, at least we would have some real information on which to base these important decisions. The proper time and place for WMF to refuse to implement this change would be AFTER the trial is over, when you can point to specific data and say, "We don't like this specific effect that we observed in the trial, and therefore we're not going to implement this change permanently." Who could argue with that? But to refuse to even implement a brief trial to gather information is inconceivable. And to point us to a hastily thrown-together workpage on mediawiki which was created yesterday (and whose ideas are also based on no real data whatsoever) as an alternative to implementing this trial is insulting. I assume that Erik speaks for the WMF with his response above (correct me if I'm wrong), and the response makes it crystal clear to me that WMF is not willing to entertain this widely endorsed trial. Needless to say, this is about as disappointing as it gets. I don't plan on continuing the begging and pleading, you've made it more than clear that you're not willing to listen. In closing, the WMF seems very concerned about how new editors are treated. Perhaps they should also consider how they treat their experienced editors who have volunteered for years. I fully realize now the extent to which the wool has been pulled over my eyes; it makes me look differently upon the hours I've spent volunteering my time here, and there isn't much else that's a stronger disincentive to continue contributing. I wish you good luck in your attempts to solve the problem by other means. I hope for everyone's sake that the WMF knows better than the 500 experienced editors who supported this trial. I don't plan on contributing to this discussion any further (unless there is a sudden change of heart), but other en-wiki editors may wish to continue discussing this with you.
The trial as proposed treats a symptom of the problem (too many bad articles created), not the actual problem (creating articles is wonky and encourages bad article creation). Erik's proposal and Brandons designs actually are aimed at the CAUSE of the problem. I'm just sayin... if I were you, I would claim that as a win.
Don't patronize us; Snottywong put a great deal of time into drafting this, and he's clearly frustrated at your response. I will expand on this tomorrow, but Rivera's going for 600 now.
I know I said I was done responding, but apparently I lied. (In reply to comment #46) > The trial as proposed treats a symptom of the problem (too many bad articles > created), not the actual problem (creating articles is wonky and encourages bad > article creation). Erik's proposal and Brandons designs actually are aimed at > the CAUSE of the problem. I'm just sayin... if I were you, I would claim that > as a win. Then we disagree on what the actual problem is. Somehow, 3.7 million articles were created using the current "wonky" system, nearly 20,000 of which are GA or better. Do you think that all we need to do to increase the quality of new articles is just punch up the interface a bit? If you really believe that the problem will be solved by adding big red and blue buttons to the article creation page, then I fear that the WMF is completely out of touch with the project they've been tasked with managing. The mediawiki workpage suffers from similar delusions, as evidenced by statements such as "Users who wish to create new pages are usually confused. The process of creating a new page is poorly understood, poorly explained, and more often than not is user-hostile." There is no evidence to support these statements, and furthermore, writing an encyclopedia article should necessarily be more difficult than posting your baseball card collection on eBay. In my opinion, it would be a mistake to devote resources to simplifying the editing interface so that more 12-year-olds and uneducated people are encouraged to create new articles. Wikipedia is an academic endeavor, not a social networking site. See [[en:WP:COMPETENCE]]. If you can't figure out how to write a new article, then perhaps you shouldn't. In my opinion (and the opinions of 400-500 other editors), your current efforts are a step in the wrong direction, but I'm just a volunteer editor and it's now clear that our opinions don't make much of a difference. I consider the WMF's response to this entire situation as anything but a win.
<First off I should say this is being said completely as a volunteer ([[User:Jamesofur]] ) and not as a staff member in any way. The only reason this is being posted from my staff email is because that's what bugzilla is set up to use> I'm sorry that you think this and I know you've worked long and hard on this. I for one am incredibly appreciative of this and all the work you've done even if I strongly disagree with your conclusions. Users have been complaining about how hard it is to edit and create pages for years and this is actually obvious on the RfC page for this bug as well where an enormous amount of people are talking about alternatives such as using a better AfC or Article Wizard to make it easier for new users and make sure they understand our policies and procedures (as obscenely diverse and awkward as they can be). I would strongly oppose your suggestion that 4-500 people in that poll agree with you that this is the wrong direction. In fact I'm not sure that I can agree with the suggestion that 500 people agreed to do this. Around 500 people commented on the poll with the most common 'support' having around 230 votes and the most common 'oppose' having around 100. They had an enormously wide variety of arguments with strong (and emotional) opinions on both sides of the arguments. Even within the 'support' group the actual arguments were widely different and a significant portion even said they supported it only if the tools like AfC were vastly improved. When you read though the opinions there I'd also say a lot of them agree that creating pages is user-hostile and far more difficult then it should be. In fact many of them used that as a REASON to support the RfC (because they thought it would be better for the new users). Obviously this is totally up to you but if you have some time I'd take a look at some of the recent research especially the Summer of Research data at http://meta.wikimedia.org/wiki/Research:Wikimedia_Summer_of_Research_2011 especially the pieces on things like what type of articles are being created . http://meta.wikimedia.org/wiki/Research:Patroller_work_load is an interesting sub study from SoR that is also directly related to this and the data oddly seems to say that the work load for patrollers (and the top patrollers) has gotten progressively less of a workload. Obviously there is a disconnect here as you guys feel overworked but I think it's a very specific pointer that something (other then crazy new users and patroller work load) is at play here. Again thank you for all your work both on this and everywhere on wiki. I'm not trying to 'convince' you I just want to point to some of the thought processes that at least I'm having. I'm also sorry to hear that you seem to think that the WMF is acting in either bad faith or just badly in general. Obviously I can be regarded as biased in this but I will tell you that every single person who has been in any way involved in this has taken it incredibly seriously. The debates have been tough and the answers not completely apparent and every single person wanted to live up to the spirit of the community and do what was best for ALL users (not just new users).
I should also mention that while I've obviously had discussions about my own opinions on this I was not in a position to influence anything Erik was doing etc. This is completely my own opinion. (sorry for email spam)
(In reply to comment #45) > On what data are you basing this opinion? The specific way that new editors > will respond to various interface changes is an extremely chaotic phenomenon, > and it would be naive to believe that anyone could accurately predict the > result of this change without any experimental data. Right, but restriction of article creation is not an interface change, it's a process/community/culture change whose effects can be predicted quite easily. > Why is the WMF so > resistant to implementing a brief trial so that we can base our opinions on > facts rather than gut reactions? Even if we implemented the trial for a > shorter period of time than 6 months, at least we would have some real > information on which to base these important decisions. I disagree: such a trial could have permanent effects despite the fast turnover of new editors, in particular because this change would necessarily produce several deep process changes which could be difficult to revert (and anyway would be a waste of time). Look, for instance, at the effects of a small change such as the mandatory summary for IP edits introduced by de.wiki in 2007: steep decrease of anonymous edits, which never reached the previous level although the change was rapidly reverted (and yes, you can blame thousands other causes, but that's valid for every trial). > In closing, the WMF seems very concerned about how new editors are treated. > Perhaps they should also consider how they treat their experienced editors who > have volunteered for years. I fully realize now the extent to which the wool > has been pulled over my eyes; it makes me look differently upon the hours I've > spent volunteering my time here, and there isn't much else that's a stronger > disincentive to continue contributing. I sympathize with you, but it's not WMF's fault if the time you spent on this discussion doesn't produce an immediate result: the point is that there is no clear consensus, as it happens frequently in our discussions; it's frustrating but it's always been like this. > I wish you good luck in your attempts to solve the problem by other means. I > hope for everyone's sake that the WMF knows better than the 500 experienced > editors who supported this trial. > > I don't plan on contributing to this discussion any further (unless there is a > sudden change of heart), but other en-wiki editors may wish to continue > discussing this with you. As I said above, I don't think that "500 editors vs. WMF" is a fair characterization of what's happening here. You might also want to consider that en.wiki is one wiki among 700+ and 270 Wikipedias: first, you should consider the experiences of other wikis and we could discover that keeping restricting new editors permissions hasn't helped; second, I don't think that the global community and the WMF can allow projects which are all called "Wikipedia" to be completely different with regard to openness and basic principles/workings – it's already strange enough that en.wiki is the only wiki with article creation restricted to registered users (ok, there are also id, fa, ta.wiki and es.books).
I, too, write this as a private individual, not as a WMF contractor. I haven't really been involved in this discussion, but something in the comments jumped out to me and I felt the need to respond to that. (In reply to comment #48) > and furthermore, writing an encyclopedia article should necessarily > be more difficult than posting your baseball card collection on eBay. In my > opinion, it would be a mistake to devote resources to simplifying the editing > interface so that more 12-year-olds and uneducated people are encouraged to > create new articles. Wikipedia is an academic endeavor, not a social > networking site. See [[en:WP:COMPETENCE]]. If you can't figure out how to > write a new article, then perhaps you shouldn't. > This quote sums up a sentiment that some people have told me exists in the Wikipedia community, but I didn't believe them until I read this comment. This anti-usability sentiment is dangerous and must be resisted. I agree that writing an encyclopedia article requires the author have expertise in the subject at hand. However, much of the expertise needed to figure out the current, confusing interface has nothing to do with the subject at hand. A law professor would be very capable of writing the initial version of an article about a new court case, but get totally lost in the article creation interface and process because he's not that good with computers. Creating a Wikipedia article is quite a few steps above using e-mail and word processing software on the technical ladder. People with no more than basic computer skills aren't all 12-year-olds or uneducated people. A lot of them are smart and knowledgeable and have something to contribute, they just aren't very good with technology. Their contributions aren't useless just because they're not good at working with computers. We need to improve the usability of our interface and process in order to attract these people; right now, we're more or less implicitly rejecting them. If we don't attract these people, we will stay in the status quo where the editor community is slanted towards male students in their 20s, and we'll have holes in our coverage for many subjects that young male students don't care about. In order to come close to gathering the sum of all human knowledge, we need to actually give all humans a fair chance of participating. This is not to say that diversifying the editor base is a magic bullet that will certainly expand the breadth of our coverage, or cause shiny pink ponies to appear out of nowhere, or anything like that. But firstly, these things are certainly not going to happen if we don't, and secondly I believe diversification is inherently better for the health of the project (and I think a few influential people agree with this). Anti-usability sentiments with arguments like "it needs to be hard or we'll be hammered by idiots" are elitist, exclusionist, and run counter to the inclusionist (in terms of people, not necessarily in terms of articles), egalitarian principles that Wikipedia was founded on.
(In reply to comment #52) > I, too, write this as a private individual, not as a WMF contractor. I haven't > really been involved in this discussion, but something in the comments jumped > out to me and I felt the need to respond to that. > > (In reply to comment #48) > > and furthermore, writing an encyclopedia article should necessarily > > be more difficult than posting your baseball card collection on eBay. In my > > opinion, it would be a mistake to devote resources to simplifying the editing > > interface so that more 12-year-olds and uneducated people are encouraged to > > create new articles. Wikipedia is an academic endeavor, not a social > > networking site. See [[en:WP:COMPETENCE]]. If you can't figure out how to > > write a new article, then perhaps you shouldn't. > > > This quote sums up a sentiment that some people have told me exists in the > Wikipedia community, but I didn't believe them until I read this comment. This > anti-usability sentiment is dangerous and must be resisted. > > I agree that writing an encyclopedia article requires the author have expertise > in the subject at hand. However, much of the expertise needed to figure out the > current, confusing interface has nothing to do with the subject at hand. A law > professor would be very capable of writing the initial version of an article > about a new court case, but get totally lost in the article creation interface > and process because he's not that good with computers. Creating a Wikipedia > article is quite a few steps above using e-mail and word processing software on > the technical ladder. > > People with no more than basic computer skills aren't all 12-year-olds or > uneducated people. A lot of them are smart and knowledgeable and have something > to contribute, they just aren't very good with technology. Their contributions > aren't useless just because they're not good at working with computers. We need > to improve the usability of our interface and process in order to attract these > people; right now, we're more or less implicitly rejecting them. If we don't > attract these people, we will stay in the status quo where the editor community > is slanted towards male students in their 20s, and we'll have holes in our > coverage for many subjects that young male students don't care about. In order > to come close to gathering the sum of all human knowledge, we need to actually > give all humans a fair chance of participating. > > This is not to say that diversifying the editor base is a magic bullet that > will certainly expand the breadth of our coverage, or cause shiny pink ponies > to appear out of nowhere, or anything like that. But firstly, these things are > certainly not going to happen if we don't, and secondly I believe > diversification is inherently better for the health of the project (and I think > a few influential people agree with this). > > Anti-usability sentiments with arguments like "it needs to be hard or we'll be > hammered by idiots" are elitist, exclusionist, and run counter to the > inclusionist (in terms of people, not necessarily in terms of articles), > egalitarian principles that Wikipedia was founded on. I don't quite understand what you are basing this message on - it appears to me to be more than little off topic and suggests sentiments that have not been made by the propoents of this change in users rights. Where were you when the RfC was held and you could have voiced your opinion?
(In reply to comment #53) > I don't quite understand what you are basing this message on - it appears > to me to be more than little off topic A bit, yes. I was refuting an argument Snottywong made in favor of the trial, though, so it seems to me that that's fair game. > and suggests sentiments that have > not been made by the propoents of this change in users rights. Eh? I replied directly to a quote from Snottywong, where this sentiment (or at least argument/reasoning, maybe sentiment is the wrong word) is quite apparent. > Where were > you when the RfC was held and you could have voiced your opinion? Like I said, I haven't been involved with this discussion. I don't have a strong opinion either way on whether page creation for non-autoconfirmed users should be allowed or not. I do, however, have a strong opinion about the "things shouldn't be made too easy" kind of arguments like the one I quoted.
(In reply to comment #54) > (In reply to comment #53) > > I don't quite understand what you are basing this message on - it appears > > to me to be more than little off topic > A bit, yes. I was refuting an argument Snottywong made in favor of the trial, > though, so it seems to me that that's fair game. > > > and suggests sentiments that have > > not been made by the propoents of this change in users rights. > Eh? I replied directly to a quote from Snottywong, where this sentiment (or at > least argument/reasoning, maybe sentiment is the wrong word) is quite apparent. > > > Where were > > you when the RfC was held and you could have voiced your opinion? > Like I said, I haven't been involved with this discussion. I don't have a > strong opinion either way on whether page creation for non-autoconfirmed users > should be allowed or not. I do, however, have a strong opinion about the > "things shouldn't be made too easy" kind of arguments like the one I quoted. In which case, with all due respect you have missed the point of the proposal for this rights change. It has nothing to do with making anything harder - it is to do with !). making it easier for serious editors to create serious articles, by simplifying the walls of text and instruction creep and introducing a truly interactive Wizard, 2) In lieu of a totally disfunctional system of new page patrolling, introducing measures that will completely prevent the creation of page that without any controversy whatsover should never be allowed to be created. pPlease read up on the original RfC, its research, and this Bugzilla discussion from the beginning.
(In reply to comment #29) > We have buckets and buckets of hard data that says this change will harm the > encyclopedia. The fact that it was ignored by those who push for this change > doesn't make it any less relevant or accurate. If you somehow missed it the > previous fifty times we published it, I suppose you can find yourself a stack > of links to it by reading the latest Signpost; it was a big topic at Wikimania. > > This change will damage (and possibly kill) the encyclopedia. It's sheer folly > to even suggest it - EVEN AS A TRIAL. > > And what a lot of new page patrollers seem to miss is this: If the workload is > so high, why are you so intent on eliminating the funnel of potential new > patrollers? It's a weird form of self-harm going on here. I'm getting tired of your aggressive comments and borderline personal attacks - it seems as if you don't care a hoot for what the unpaid volunteers do here. You have not provided any stats that prove that this measure will be detrimental to the Wikipedia. You have ignored the background to this new rule, and refused to read the RfC (because it takes 3 hours to wade through). Please adopt a more respectful tone when slapping the work of dedicated Wkipedians in the face, and think of the volunteers you paid WMFers will lose if you continue on this tack. All you did at Wikimania was to publish a flyer full of proven lies to reinforce your mantra. New Page Patrol is a completely broken process - it's operated by the least experienced of all editors and children who refuse to read the instruction or understand the policies involved. The proponents of this new user right have proven that much - with real stats.
(In reply to comment #51) > (In reply to comment #45) > > On what data are you basing this opinion? The specific way that new editors > > will respond to various interface changes is an extremely chaotic phenomenon, > > and it would be naive to believe that anyone could accurately predict the > > result of this change without any experimental data. > > Right, but restriction of article creation is not an interface change, it's a > process/community/culture change whose effects can be predicted quite easily. > > > Why is the WMF so > > resistant to implementing a brief trial so that we can base our opinions on > > facts rather than gut reactions? Even if we implemented the trial for a > > shorter period of time than 6 months, at least we would have some real > > information on which to base these important decisions. > > I disagree: such a trial could have permanent effects despite the fast turnover > of new editors, in particular because this change would necessarily produce > several deep process changes which could be difficult to revert (and anyway > would be a waste of time). > Look, for instance, at the effects of a small change such as the mandatory > summary for IP edits introduced by de.wiki in 2007: steep decrease of anonymous > edits, which never reached the previous level although the change was rapidly > reverted (and yes, you can blame thousands other causes, but that's valid for > every trial). > > > In closing, the WMF seems very concerned about how new editors are treated. > > Perhaps they should also consider how they treat their experienced editors who > > have volunteered for years. I fully realize now the extent to which the wool > > has been pulled over my eyes; it makes me look differently upon the hours I've > > spent volunteering my time here, and there isn't much else that's a stronger > > disincentive to continue contributing. > > I sympathize with you, but it's not WMF's fault if the time you spent on this > discussion doesn't produce an immediate result: the point is that there is no > clear consensus, as it happens frequently in our discussions; it's frustrating > but it's always been like this. > > > I wish you good luck in your attempts to solve the problem by other means. I > > hope for everyone's sake that the WMF knows better than the 500 experienced > > editors who supported this trial. > > > > I don't plan on contributing to this discussion any further (unless there is a > > sudden change of heart), but other en-wiki editors may wish to continue > > discussing this with you. > > As I said above, I don't think that "500 editors vs. WMF" is a fair > characterization of what's happening here. You might also want to consider that > en.wiki is one wiki among 700+ and 270 Wikipedias: first, you should consider > the experiences of other wikis and we could discover that keeping restricting > new editors permissions hasn't helped; second, I don't think that the global > community and the WMF can allow projects which are all called "Wikipedia" to be > completely different with regard to openness and basic principles/workings – > it's already strange enough that en.wiki is the only wiki with article creation > restricted to registered users (ok, there are also id, fa, ta.wiki and > es.books). There is nothing strange about it - no other Wiki has to contend with the huge daily influx of *totally* unacceptable new pages. This is probably not easy for anyone to understand who has not spent 100s of hours patrolling new pages and patrolling the people who are supposed to be patrolling them, and then physically deleting them or indeed removing incorrect CSD templates. One needs to consider that one or even five WMF voices are not even five of the 500 who took part in the RfC and led it to a clear consensus on a solution for an urgent and serious problem. The WMF voices are even less significant among the tens of thousands of other editors who actually do the work of maintaining quality and who provide content. The en.Wiki is more than just a usa.Wiki, it addresses the entire English speaking world of billions and cannot be compared with the minor Wikis - not even with the French and German ones whose languages are shared by several nations. Ironically, in other ares of major policy, some of those other Wikis are significantly stricter than en.Wiki, but I don't see the WMF interfering with them. By not accepting necessary change, there is likely to be an exodus of the very experienced editors that are needed - the WMF needs to decide who is more important: the gnomes in the background who with their thousands of monthly n intelligent edits put the project where it is today, an keep it ticking over, or the vandals, spammers, attackers. and BLP SPAs - none of whom are likely to become seriously minded contributors.
(In reply to comment #46) > The trial as proposed treats a symptom of the problem (too many bad articles > created), not the actual problem (creating articles is wonky and encourages bad > article creation). Erik's proposal and Brandons designs actually are aimed at > the CAUSE of the problem. I'm just sayin... if I were you, I would claim that > as a win. I wish that some of the WMF developers and staff would take a day off from your normal duties, and do the following to get a perspective on what's going on here: Go to Special:NewPages, and find the list of articles that were created about 10-15 days ago. Pick a day, and patrol the entire list of articles that were created in that 24-hour period (which will be missing the very worst articles which would have been weeded out by the people who patrol the front of the queue). Then, patrol the front of the queue for a few hours to get a raw look at the stream of the worst articles that are constantly getting speedy deleted. At the end of that process, you should have a much better perspective on the state of new article creation at en-wiki. If you want to go even deeper, start taking a look at articles that have been recently patrolled to get a sense for the types of articles that the average new page patroller is letting through the gate. At the end of that process, you'll realize that any efforts to make it easier and more user-friendly to create new articles will not increase the quality of new articles, it will only make it easier for people to create more shitty articles. Making the editing interface more user-friendly is not a bad thing, but it is not a solution to the problem of the vast torrent of shitty new articles that are currently getting through the gates. What is needed is the following: 1. New WP users need to be filtered into two categories: users who genuinely want to and are capable of contributing encyclopedic content, and users who want to contribute spam, copyvios, and non-notable content and then leave. 2. The latter group should not be allowed to easily create new articles without jumping through some hoops to deter them. The former group should be educated on what Wikipedia is about, how it works, and what is expected in a new article. The proposed trial provides the deterrent to the non-serious editors, AND provides a small hurdle for serious editors to get over, which if designed correctly, that time could be used to properly educate them and get them the experience they need to successfully create a great new article, thereby sparing them the stress of having their new article deleted. I just want to make sure my previous comments were not misunderstood: Improving the editing interface is a good thing; it will allow non-techie people to contribute. This is a good thing, but it does nothing to solve the problem of editors who are already savvy enough to figure out how to create a new article, but couldn't care less about WP policies, notability, copyright issues, spam policies, etc., and aren't serious about contributing encyclopedic content. And there is a steady stream of these types of people. The proposed trial is an attempt to solve one problem, and your response is to deflect us to a completely separate problem. This is the source of our frustration.
Hi, I'll post some additional thoughts later today or tomorrow, but wanted to post a quick note just thanking everyone who's posted here, and re-stating that we're here to listen and help. That doesn't mean slavish execution of any request that has a high degree of support, no matter how potentially problematic we think it may be. But it does mean that we're not ignoring comments at all, including concerns about new page patroller workload, low quality articles, etc. I would again request detailed consideration of the page we've posted, which is far from perfect, but which does discuss more issues than just usability. http://www.mediawiki.org/wiki/ArticleCreationWorkflow If this discussion is making you really frustrated, I'd also suggest just taking a break from it. Our intent here isn't to ram anything through -- it's to listen & figure out a way forward. Let's get out of the "us vs. them" and look at this problem together, realizing that there are different views which all have value and grounding in reality. Thanks, Erik
I don't know where anyone is getting the idea that there was "no clear consensus". The proposal was closed by an admin, who made an extremely detailed summary of what the consensus was; that we should go ahead with a trial. Unless you'd like us to present you with a shrubbery and chop down the tallest tree in the woods with a herring, I don't know how else we could have possibly gotten a clearer consensus. I would pay very close attention to comments 57 and 58; I was one of the most prolific NPPers for the last year, and I can confirm everything said above. I would argue that making new users go through AfC will be easier, because instead of reading pages on how to create articles they can actually work WITH an experienced user. I've worked some at AfC now, and the users there are very friendly and accommodating. That will be a much better experience for new users than reading through a huge ream of text.
(In reply to comment #58) > I just want to make sure my previous comments were not misunderstood: > Improving the editing interface is a good thing; it will allow non-techie > people to contribute. This is a good thing, Thank you, now I can continue assuming good faith and doubting that editors who are against making things easier exist :) > but it does nothing to solve the > problem of editors who are already savvy enough to figure out how to create a > new article, but couldn't care less about WP policies, notability, copyright > issues, spam policies, etc., and aren't serious about contributing encyclopedic > content. And there is a steady stream of these types of people. > > The proposed trial is an attempt to solve one problem, and your response is to > deflect us to a completely separate problem. This is the source of our > frustration. As I said before I don't really want to get drawn into this discussion, so I'll just drop this little bit: I've glanced over Erik's proposal and it seems to address both issues, simplifying the interface and process while also implementing an incubation namespace/workspace/whatever where new articles that are submitted by inexperienced users or that don't match certain criteria can be improved upon, reviewed, and admitted to the main namespace (or rejected and left to rot). So Erik's proposal still addresses the original problem. I also don't believe the problems are completely separate (some bad new articles, not the flat-out garbage ones but the not-quite-good-enough ones, are probably the way the are because people can't figure out how to write them properly), but that's hardly important enough to argue about right now.
(In reply to comment #61) > I've glanced over Erik's proposal and it seems to > address both issues, simplifying the interface and process while also > implementing an incubation namespace/workspace/whatever where new articles that > are submitted by inexperienced users or that don't match certain criteria can > be improved upon, reviewed, and admitted to the main namespace (or rejected and > left to rot). As far as I can tell, the proposal is to create a noindexed workspace area, and "highly encourage" (but don't require) new users to create their article in that workspace first. Then, without any kind of review process at all, they can move their article into mainspace whenever they want. In my opinion, this is an idea which only complicates the article creation process (by giving new users more options to choose from which they don't understand) while simultaneously not implementing any steps which would prevent a new user from creating a new article (in mainspace) on their high school chess club. This proposal doesn't address the problem whatsoever. Any real solution to the problem will involve some level of forcibly disallowing new users from creating new articles until certain conditions are met which guarantee some minimal level of education about Wikipedia and how it works; and simply registering a user account does not provide any such guarantee. This is the stumbling block, and this is the part of the proposal which WMF apparently rejects, without the support of any real data on what the consequences would be. We're simply asking for a chance to collect that data, that is all. Personally, I'd be happy if the trial was only implemented for 1-2 months, but I can't speak for the rest of the editors who are pulling for a 6-month trial.
(In reply to comment #62) > (In reply to comment #61) > > I've glanced over Erik's proposal and it seems to > > address both issues, simplifying the interface and process while also > > implementing an incubation namespace/workspace/whatever where new articles that > > are submitted by inexperienced users or that don't match certain criteria can > > be improved upon, reviewed, and admitted to the main namespace (or rejected and > > left to rot). > > As far as I can tell, the proposal is to create a noindexed workspace area, and > "highly encourage" (but don't require) new users to create their article in > that workspace first. Then, without any kind of review process at all, they > can move their article into mainspace whenever they want. In my opinion, this > is an idea which only complicates the article creation process (by giving new > users more options to choose from which they don't understand) while > simultaneously not implementing any steps which would prevent a new user from > creating a new article (in mainspace) on their high school chess club. > > This proposal doesn't address the problem whatsoever. Any real solution to the > problem will involve some level of forcibly disallowing new users from creating > new articles until certain conditions are met which guarantee some minimal > level of education about Wikipedia and how it works; and simply registering a > user account does not provide any such guarantee. This is the stumbling block, > and this is the part of the proposal which WMF apparently rejects, without the > support of any real data on what the consequences would be. We're simply > asking for a chance to collect that data, that is all. Personally, I'd be > happy if the trial was only implemented for 1-2 months, but I can't speak for > the rest of the editors who are pulling for a 6-month trial. Perhaps unsurprisingly, that's pretty much exactly what I was thinking. You can't solve this problem by creating more intricacy; the concept of requiring autoconfirmed status is an application of Ockham's razor (or Occam's, whatever your preference); it's supposed to make the process as simple as possible for everyone. I have laid out why I think this is the case in Comment 61, though I can give more detail if requested.
(In reply to comment #58) > (In reply to comment #46) > > The trial as proposed treats a symptom of the problem (too many bad articles > > created), not the actual problem (creating articles is wonky and encourages bad > > article creation). Erik's proposal and Brandons designs actually are aimed at > > the CAUSE of the problem. I'm just sayin... if I were you, I would claim that > > as a win. > > I wish that some of the WMF developers and staff would take a day off from your > normal duties, and do the following to get a perspective on what's going on > here: Go to Special:NewPages, and find the list of articles that were created > about 10-15 days ago. Pick a day, and patrol the entire list of articles that > were created in that 24-hour period (which will be missing the very worst > articles which would have been weeded out by the people who patrol the front of > the queue). Then, patrol the front of the queue for a few hours to get a raw > look at the stream of the worst articles that are constantly getting speedy > deleted. At the end of that process, you should have a much better perspective > on the state of new article creation at en-wiki. > I haven't commented here yet, but I just wanted to make two points: 1). It's a myth that no one on staff is a Wikipedian and that we have zero experience dealing with new pages and new editors. There are others including Erik, but as examples Philippe and I are both active English Wikipedia admins who have deleted thousands of pages between us. We know exactly how much crap flows in to the project. 2). Actually I think as part of our work on this, I would be happy to commit to doing a solid chunk of New Page Patrol in my off time. I've worked CSD and similar spaces before, but not done work through Special:NewPages substantially.
(In reply to comment #55) > In which case, with all due respect you have missed the point of the > proposal for this rights change. It has nothing to do with making > anything harder - it is to do with !). making it easier for serious > editors to create serious articles, by simplifying the walls of text and > instruction creep and introducing a truly interactive Wizard, Great. What if we start by introducing that, and *then* decide if a) it still needs more work (got o point 0) b) it is good enough, we should try to forbid creation except using it c) it is a fantastic system that should replace default editing d) it convinces anyone to not introduce shitty articles into the wiki etc. Note that such work would need several months, and it would be desired to have that *before* restricting the article creation (that's also what some people manifested in the voting). (In reply to comment #58) > 1. New WP users need to be filtered into two categories: users who genuinely > want to and are capable of contributing encyclopedic content, and users who > want to contribute spam, copyvios, and non-notable content and then leave. > 2. The latter group should not be allowed to easily create new articles > without jumping through some hoops to deter them. The former group should be > educated on what Wikipedia is about, how it works, and what is expected in a > new article. Yes, but How to do that? > The proposed trial provides the deterrent to the non-serious editors, AND > provides a small hurdle for serious editors to get over, which if designed > correctly, that time could be used to properly educate them and get them the > experience they need to successfully create a great new article, One of the greatest strengths of Wikipedia is its immediateness. If a scholar needs to wait four days for creating the article, he may no longer be interested in doing so (just as well as the 12-yo you want to hold back, or even more, since the "12yo" is more likely to create accounts everywhere). (In reply to comment #62) > As far as I can tell, the proposal is to create a noindexed workspace area, > and "highly encourage" (but don't require) new users to create their article > in that workspace first. Then, without any kind of review process at all, > they can move their article into mainspace whenever they want. That's not what I understood. Plus, you could easily add a review before moving to main namespace (just make it a big "Publish now" button instead of "Manually add the page at the bottom of Wikipedia:Pending reviews"). There's also a mention of AbuseFilter quality checks in that page (although imho that's problematic).
Hi guys! I think at this point it would probably be best to move this discussion off bugzilla and onto the wiki page about the issue itself: http://www.mediawiki.org/wiki/ArticleCreationWorkflow That way, we can be more inclusive as to who gets to read and reply to all the information here.
I definitely agree we should be focusing on making it easier for new users to put in pages that may not be that great, but can be expanded on by others without being deleted. Take this article, for instance: http://en.wikipedia.org/w/index.php?title=CobraNet&oldid=115793918 I'd imagine that article would likely get speedy deleted now a days.
(In reply to comment #66) > Hi guys! > > I think at this point it would probably be best to move this discussion off > bugzilla and onto the wiki page about the issue itself: > > http://www.mediawiki.org/wiki/ArticleCreationWorkflow > > That way, we can be more inclusive as to who gets to read and reply to all the > information here. And in response to comment 65; the best thing to do would be to implement the simple solution (the consensus at the above mentioned RfC) NOW, then figure out the MediaWiki issues, which will take a lot of fine-tuning. And if a scholar seriously can't wait 4 days and make 10 edits before publishing an article, I don't think that's a scholar who will be very successful in academia; you don't get to walk up to academic journals and demand they publish your paper. You normally have to have certain credentials to get published, although exceptions can be made. Same as what we're asking; we want people to have a certain level of experience, but we can make exceptions (admins granting the confirmed flag) as they arise.
(In reply to comment #68) > And in response to comment 65; the best thing to do would be to implement the > simple solution (the consensus at the above mentioned RfC) NOW, then figure out > the MediaWiki issues, which will take a lot of fine-tuning. I think we're spinning wheels here, guys. This has ceased to be a discussion about the bug (which isn't going to be implemented, as far as I know) and moved into ideological arguments, which are better spent on a wiki where everyone can edit. So, can we please move the discussion to [[mw:ArticleCreationWorkflow]] now?
(In reply to comment #68) > And in response to comment 65; the best thing to do would be to implement the > simple solution (the consensus at the above mentioned RfC) NOW, then figure out > the MediaWiki issues, which will take a lot of fine-tuning. And if a scholar > seriously can't wait 4 days and make 10 edits before publishing an article, I > don't think that's a scholar who will be very successful in academia; you don't > get to walk up to academic journals and demand they publish your paper. You > normally have to have certain credentials to get published, although exceptions > can be made. Same as what we're asking; we want people to have a certain level > of experience, but we can make exceptions (admins granting the confirmed flag) > as they arise. Since when is Wikipedia an encyclopedia that only experts can edit? I thought it was an encyclopedia that anyone can edit? We need to consider the person that can read about a subject, write articles, and make references to original research based on the information they found, whether they are technical or not. Someone editing Wikipedia in their spare time, contributing useful information may not wait 4 days. They may never come back.
(In reply to comment #70) > (In reply to comment #68) > > And in response to comment 65; the best thing to do would be to implement the > > simple solution (the consensus at the above mentioned RfC) NOW, then figure out > > the MediaWiki issues, which will take a lot of fine-tuning. And if a scholar > > seriously can't wait 4 days and make 10 edits before publishing an article, I > > don't think that's a scholar who will be very successful in academia; you don't > > get to walk up to academic journals and demand they publish your paper. You > > normally have to have certain credentials to get published, although exceptions > > can be made. Same as what we're asking; we want people to have a certain level > > of experience, but we can make exceptions (admins granting the confirmed flag) > > as they arise. > > Since when is Wikipedia an encyclopedia that only experts can edit? I thought > it was an encyclopedia that anyone can edit? We need to consider the person > that can read about a subject, write articles, and make references to original > research based on the information they found, whether they are technical or > not. > > Someone editing Wikipedia in their spare time, contributing useful information > may not wait 4 days. They may never come back. Experience meaning "autoconfirmed status". I thought it was apparent what I meant.
(In reply to comment #57) > (In reply to comment #51) > > As I said above, I don't think that "500 editors vs. WMF" is a fair > > characterization of what's happening here. You might also want to consider that > > en.wiki is one wiki among 700+ and 270 Wikipedias: first, you should consider > > the experiences of other wikis and we could discover that keeping restricting > > new editors permissions hasn't helped; second, I don't think that the global > > community and the WMF can allow projects which are all called "Wikipedia" to be > > completely different with regard to openness and basic principles/workings – > > it's already strange enough that en.wiki is the only wiki with article creation > > restricted to registered users (ok, there are also id, fa, ta.wiki and > > es.books). > > There is nothing strange about it - no other Wiki has to contend with the > huge daily influx of *totally* unacceptable new pages. This is probably not > easy for anyone to understand who has not spent 100s of hours patrolling > new pages and patrolling the people who are supposed to be patrolling them, > and then physically deleting them or indeed removing incorrect CSD templates. [...] Please stop telling people they don't have a right to express their opinions. Your argument is weak, because small wikis have also less patroller. And, by the way, your personal argument is nonsense; I've spent not hundreds but probably thousands of hours patrolling in the last 5+ years.
(In reply to comment #72) > (In reply to comment #57) > > (In reply to comment #51) > > > As I said above, I don't think that "500 editors vs. WMF" is a fair > > > characterization of what's happening here. You might also want to consider that > > > en.wiki is one wiki among 700+ and 270 Wikipedias: first, you should consider > > > the experiences of other wikis and we could discover that keeping restricting > > > new editors permissions hasn't helped; second, I don't think that the global > > > community and the WMF can allow projects which are all called "Wikipedia" to be > > > completely different with regard to openness and basic principles/workings – > > > it's already strange enough that en.wiki is the only wiki with article creation > > > restricted to registered users (ok, there are also id, fa, ta.wiki and > > > es.books). > > > > There is nothing strange about it - no other Wiki has to contend with the > > huge daily influx of *totally* unacceptable new pages. This is probably not > > easy for anyone to understand who has not spent 100s of hours patrolling > > new pages and patrolling the people who are supposed to be patrolling them, > > and then physically deleting them or indeed removing incorrect CSD templates. [...] > > Please stop telling people they don't have a right to express their opinions. > Your argument is weak, because small wikis have also less patroller. > And, by the way, your personal argument is nonsense; I've spent not hundreds > but probably thousands of hours patrolling in the last 5+ years. Huh? He never said you couldn't express your opinion. He merely said that it takes some experience to understand why people would want a change like this.
(In reply to comment #67) > Take this article, for instance: > http://en.wikipedia.org/w/index.php?title=CobraNet&oldid=115793918 > > I'd imagine that article would likely get speedy deleted now a days. A very nice jab at the first article I created, but your lack of knowledge is showing. If you have any familiarity with enwiki's speedy deletion criteria, you'd realize that even that stub doesn't qualify for speedy deletion. It asserts the notability of the subject when it says that it "is widely regarded as the first commercially successful implementation of audio over Ethernet." You can't speedy delete an article ONLY for not having references. And if you look merely one day later (http://en.wikipedia.org/w/index.php?title=CobraNet&oldid=116324830) you'll see references have been added. If you have ever spent any time doing new page patrolling, you'd know that all but the most terrible articles spend at least 15-30 days on the newpages queue before a patroller gets around to reviewing it. The users who patrol the front of the queue generally only look at obvious vandalism articles. (In reply to comment #70) > Someone editing Wikipedia in their spare time, contributing useful information > may not wait 4 days. They may never come back. Then they probably wouldn't have stayed anyway. 4 days and 10 edits is not a large commitment, considering that most experienced longtime editors have well over 10,000 edits over the course of many years. In any case, all of these types of emotionally charged statements about what will or won't happen if we restrict article creation are all based on gut reactions. Wouldn't it be infinitely better if we could implement a brief trial, and then make well-informed statements like "exactly 22% of users who tried to create an article but were informed they couldn't did not eventually create their page and never came back." I would certainly prefer to have an intelligent conversation based on facts rather than trading anecdotes and gut feelings. (In reply to comment #69) > So, can we please move the discussion to [[mw:ArticleCreationWorkflow]] now? [[mw:ArticleCreationWorkflow]] doesn't discuss any real solutions to the problem, so I will not be contributing there. I agree that this bug report has served its purpose, so I'll mark it as resolved.
(In reply to comment #73) > Huh? He never said you couldn't express your opinion. He merely said that it > takes some experience to understand why people would want a change like this. This is obviously true in some ways but is also obviously not something true across the board. As Nemo said he's done an awful lot of patrolling himself and one of the most adamant opposers in the RfC (Ironholds) has spent years doing more patrolling then basically anyone has done this year (as can be seen at http://meta.wikimedia.org/wiki/Research:Patroller_work_load#Results_and_discussion I actually knew he had done a lot didn't realize he'd done THAT much until last night when I looked). I'm being bad too, the bug report has obviously gone into a discussion that is no longer relevant here.
(In reply to comment #73) > (In reply to comment #72) --->8 [SNIP] 8<---- > > Please stop telling people they don't have a right to express their opinions. > > Your argument is weak, because small wikis have also less patroller. > > And, by the way, your personal argument is nonsense; I've spent not hundreds > > but probably thousands of hours patrolling in the last 5+ years. > > Huh? He never said you couldn't express your opinion. He merely said that it > takes some experience to understand why people would want a change like this. I think Nemo is trying to say that "yes, many people here understand exactly what you're talking about." You'll have to remember that several people commenting here have been involved with the movement since its inception and have done their fair share of the work you're describing. These problems are not unknown to us (the developers and the Foundation). No one saying that there is *not* a problem - far from it, I think: there is widespread agreement that there is a quality/quantity problem with regards to new article creation. However, the general consensus about the interpretation of the data we have (see above, in James Alexander's excellent comment) is that an autoconfirmed trial would produce less-than-desirable results. And (as was pointed out above), such a move, even in trial format, would have long-lasting social ramifications. Relax! You scored a victory! Your concerns have been heard and marked as a priority. Attempts are being made to address them. The Foundation has now dedicated a lot of resources towards this problem. I can't promise that anything will be developed immediately (we are resource constrained) but it *will* happen. As to why we don't implement the trial while we wait for better solutions, we come back to the "long lasting social implications". Wikimedia projects already have a reputation of being insular and exclusionary; we have been working very hard to reverse this impression. Implementing something now - even in the short term - would only reinforce this impression to the public at large. We're all trying to do what's best for the project, believe me.
(In reply to comment #74) > > [[mw:ArticleCreationWorkflow]] doesn't discuss any real solutions to the > problem, so I will not be contributing there. I really wish you would. That page is about trying to design the best solution, and your contributions would be valuable there. I'm sorry that things are not working out the way you'd hoped, but I applaud your efforts. Again: we're all on the same side here - the side of trying to make the best encyclopedia possible.
(In reply to comment #74) > A very nice jab at the first article I created, but your lack of knowledge is > showing. If you have any familiarity with enwiki's speedy deletion criteria, > you'd realize that even that stub doesn't qualify for speedy deletion. It > asserts the notability of the subject when it says that it "is widely regarded > as the first commercially successful implementation of audio over Ethernet." > You can't speedy delete an article ONLY for not having references. And if you > look merely one day later > (http://en.wikipedia.org/w/index.php?title=CobraNet&oldid=116324830) you'll see > references have been added. If you have ever spent any time doing new page > patrolling, you'd know that all but the most terrible articles spend at least > 15-30 days on the newpages queue before a patroller gets around to reviewing > it. The users who patrol the front of the queue generally only look at obvious > vandalism articles. > I was just pointing out that your very first edit was creating a new page. It was a stub with no references on a subject I've never heard of (and I've been doing tech stuff since I was super young). It very likely would be deleted in today's environment. Of course, it shouldn't be... If this policy was in place, you couldn't have made that article, and it's possible you wouldn't be an editor now. We appreciate your work, and we'd like to appreciate the work of future editors as well. I'd like for us to help and mentor the noobs instead of biting them. Hand-holding is better than hand-slapping, and taking away a right from a new user is the latter. We are proposing the former.
(In reply to comment #74) > > Someone editing Wikipedia in their spare time, contributing useful information > > may not wait 4 days. They may never come back. > > Then they probably wouldn't have stayed anyway. I disagree. > 4 days and 10 edits is not a > large commitment, considering that most experienced longtime editors have well > over 10,000 edits over the course of many years. It's very different to set such kind of requirement (or others much higher) for things like votations, and for core features like creating a page. If person A wants to create an article about Foomatics, *on his own time*, *for free*, requiring him to eg. "patrol 10 pages before doing that" will not encourage new editors to stay.
(In reply to comment #79) > (In reply to comment #74) > > > Someone editing Wikipedia in their spare time, contributing useful information > > > may not wait 4 days. They may never come back. > > > > Then they probably wouldn't have stayed anyway. > I disagree. > > > 4 days and 10 edits is not a > > large commitment, considering that most experienced longtime editors have well > > over 10,000 edits over the course of many years. > > It's very different to set such kind of requirement (or others much higher) for > things like votations, and for core features like creating a page. > > If person A wants to create an article about Foomatics, *on his own time*, *for > free*, requiring him to eg. "patrol 10 pages before doing that" will not > encourage new editors to stay. We get that you don't agree with us, but we have the stats on our side; nonetheless, this bug is (for the time being, at least) marked as resolved, won't fix. Let it go.
(In reply to comment #3) > The right way to deal with this is to cut to the root of the problem: we throw > brand-new potential editors directly into shark-infested waters, then yell at > them for splashing at the sharks. :) > > I agree with the basic concern -- putting newbies right into that environment > so easily often ends up harming everyone -- but I don't think it would be ideal > to simply cut off new article creation without actually providing a safe place > for them to go instead. > > > This needs to be paired with a *really good user-friendly way* for new accounts > to create provisional articles, have them reviewed, get mentored by real > people, and get their articles moved into real article space (or at least end > up finding something better to do in a less confrontational way than a scary > template and speedy deletion). > > I would recommend at least a serious beefing up of the requests for article > creation pages before trying this; a newbie attempting to create a new article > definitely needs to be shepherded through some checks, and should end up with > the opportunity to at least create a page -- even if it's in a sandbox area. > > (In the future, please consider actually reaching out to developers for > feedback as well before the final stages!) In future, please consider reading up on the 13 months of background research for this new rule proposal and the reasons for it (http://en.wikipedia.org/wiki/Wikipedia:NPP), and take note that its proponents have offered three parallel alternative methods for fast-tracking the serious articles for live publication - hardly the work of a bunch of dedicated exclusionists. This could be easily done by according a new user right of, for example, New Page Reviewer, as is done on the German Wiki.
(In reply to comment #80) > (In reply to comment #79) > > (In reply to comment #74) > > > > Someone editing Wikipedia in their spare time, contributing useful information > > > > may not wait 4 days. They may never come back. > > > > > > Then they probably wouldn't have stayed anyway. > > I disagree. > > > > > 4 days and 10 edits is not a > > > large commitment, considering that most experienced longtime editors have well > > > over 10,000 edits over the course of many years. > > > > It's very different to set such kind of requirement (or others much higher) for > > things like votations, and for core features like creating a page. > > > > If person A wants to create an article about Foomatics, *on his own time*, *for > > free*, requiring him to eg. "patrol 10 pages before doing that" will not > > encourage new editors to stay. > > We get that you don't agree with us, but we have the stats on our side; > nonetheless, this bug is (for the time being, at least) marked as resolved, > won't fix. Let it go. I've reopened this - it's long from finished. The refusal to conduct this trial is based not on 'buckets' of stats, for there aren't any. It's based on some 'stats' of extremely dubious provenance that were made up and published at Wikimedia. The refusal to allow this trial is not based on a decision of the WMF, it's a unilateral decision by one or two single-minded WMF staffers whose paid status has gone to their heads - to the extent even that they can't even keep a civil tongue in his head when posting here. What is more important? - continuing to allow free rein to the vandals, attackers, and spammers under the completely and utterly false assumption that 30% of our best editors began their Wiki career as vandals,? Or to to encourage serious editors to wait an hour or so before their new article goes live - and above all doing more to retain the good contributors that we already have and desperately need. The attitudes expressed here purportedly in the name of the WMF, have already sown the seeds of exodus from the Wikipedia of some of our most competent contributors and policy watchers - is that what is wanted?
(In reply to comment #1) > Call me dumb, but don't see any strong consensus here. If we simply sum the > number of people supporting and opposing this change in principle, it will be > something closer to 50/50. Also, lots of people opined on the need in an > article creation wizard in software proper, as opposed to wiki pages. Can this > possibility be seriously discussed before making such serious step? OK Max, I'm afraid I have to call you dumb ;) Not only was there a blatantly clear consensus, but the RfC was closed and summarised by an extremely competent and highly experienced user. It would take over three hours to explore the hundreds of comments on the RfC and its talk page, and I would suggest that if you have the best interests of Wikipedia at heat, you could at least invest the same amount of time and base your comments here on reality.
(In reply to comment #21) > To fill up everyone's inboxes just that little bit more, I think it's worth > rebutting the above inaccuracy: > > > Wikipedia is indeed the encyclopedia anyone can edit. There has however, never > > been a policy that anyone can create new pages. > > Sorry, but this is just wrong. All users, anonymous and otherwise, used to be > able to create articles. It was a right that was "temporarily" suspended after > the Seigenthaler issue in 2006, pending the creation of a system that would let > us review changes before they went live. The fact that said system - Flagged > Revisions, created to return us to the status quo (that is, one in which > anonymous users can create articles) - has run into difficulties with the > community does not mean that the idea that it's settled policy that there's no > policy that all users can create new pages. > > I worry that this throws more heat than light on the situation, but we can't go > around making massive changes to the community interaction model whilst at the > same time relaying false and damaging claims about our intent, which don't help > anyone. No one is making 'massive changes' without a trial. Only a trial can prove who is right and who is wrong. The developers of the trial have taken every avenue into consideration, including the 12 months of research that preceded it. The opinions of those who oppose this new, are driven purely by 1) emotion, and 2). by the power of authority vested in them as paid employees of the WMF.
(In reply to comment #25) > (In reply to comment #23) > > > This can be done with a one-line hook, no changes in core are needed, I think. > > > [[mw:Manual:Preventing_access#Restrict_page_creation_in_certain_namespaces]] > seems to say that they would have to use an extension (which is beta and would > need a thorough security review and make sure it can scale to our size) or a > core change. That would be up to the developers however. This is no more difficult than some of the user groups that have been created at the German Wiki for patrolling recent changes and new pages.
Hi folks, this will be my last comment on this bug, as I don't think this is the right place to have further useful discussions. I empathize with expressions of anger and frustration, and I'm very sorry that we haven't been able to handle this issue in a way that minimizes both. With that said - if your view of WMF is that the only legitimate engagement toward a request like this one is to execute it, then there's not much point in continuing a conversation. That's simply not our view, nor has it ever been our practice. My own take is pretty straightforward: The community has certain blind spots and biases; WMF has certain blind spots and biases. Having spent years deeply immersed in both, I can safely say that the two are very different animals. For example, WMF has recently completed the most comprehensive research program ever conducted into a huge variety of questions related to editor retention ( see http://meta.wikimedia.org/wiki/Research:Wikimedia_Summer_of_Research_2011 ). That's the kind of program that requires organizational support and coordination to succeed, and it's yielded some incredibly important insights, many of which are probably still unknown to the average Wikimedian. But that's a very different perspective from that of, say, our most active new page patrollers, who will know tons of things from first-hand experience that, at least to the WMF folks who haven't been doing NPP Work recently or ever, aren't obvious at all. So, I think if we want to seriously solve the problems we all know exist, we'll need to bring different experiences and viewpoints together to eliminate blind spots. When we act purely on the basis of our own biases, we make mistakes. We avoid mistakes by listening, and by collaborating especially with people who bring perspectives outside our own field of view. (In our context, that should also include perspectives from other language Wikipedias and sister projects.) In other words, I am not at all asserting that the ideas that we've been kicking around and sharing with you are the right ideas. I am, however, saying that we'll get much closer to doing the right things in the right way by making a real effort to work together. I think the recent discussions that have kicked off on the http://www.mediawiki.org/wiki/Article_creation_workflow are taking us in the right direction at looking at the problem from very different perspectives. You'll find me there, and I hope we can find a tone of equal partnership in digging into the complex social and technical problems we've been talking about. This will take time, but I think it's worth it to get this right.
Feel free to disseminate this to any relevant parties on-wiki. At en.wikibooks, we use very specific naming for books (title case) and had a problem with many new users creating "test pages" at various search terms. Most pages are going to be created from existing links and the creation of a new book is a serious endeavor and should only be performed by those familiar with local conventions. So what we did was modify MediaWiki:Searchmenu-new. It now offers to search at en.wiki or en.wikiversity rather than pushing the creation of a new page. Now instead of deleting test pages all day we see almost none created. My suggestion is that en.wiki alter the content of that interface message to point to the article creation wizard, possibly also tracking what search term was used to get to the wizard to preload the term into the destination for the workspace. The search results page is place where many new users see the possibility to create a new article. Alter the workflow there with MediaWiki:Searchmenu-new and you will see a difference as I've personally seen at en.wikibooks. No developer involvement needed.
(In reply to comment #82) > I've reopened this - it's long from finished. The refusal to conduct this > trial is based not on 'buckets' of stats, for there aren't any. It's based > on some 'stats' of extremely dubious provenance that were made up and > published at Wikimedia. The refusal to allow this trial is not based on a > decision of the WMF, it's a unilateral decision by one or two single-minded > WMF staffers whose paid status has gone to their heads - to the extent even > that they can't even keep a civil tongue in his head when posting here. You, as do many people, misunderstand the meaning of the "Status" and "Resolution" fields; a bug does not have to be open to be a legitimate venue for discussion (bugs which should be silenced are marked as Closed). The Status reflects precisely that: the current sentiment about the bug. That current sentiment is that several senior sysadmins have stated that the requested change will not be made. Unlike the wiki you are used to, there is a well-established (if loose) hierarchy within the developers which means that that decision will not be overturned without their agreement. Now that change can happen, driven by discussion and progress here, on the mw.org page linked to in numerous comments above, or elsewhere. It can happen by convincing those who have already taken a position to rethink it, by convincing other sysadmins of a similar level, or by convincing higher authorities to overrule them. It cannot happen by simply reopening the bug and hoping that, if you wish hard enough, reality will magically readjust.
(In reply to comment #88) > (In reply to comment #82) > > I've reopened this - it's long from finished. The refusal to conduct this > > trial is based not on 'buckets' of stats, for there aren't any. It's based > > on some 'stats' of extremely dubious provenance that were made up and > > published at Wikimedia. The refusal to allow this trial is not based on a > > decision of the WMF, it's a unilateral decision by one or two single-minded > > WMF staffers whose paid status has gone to their heads - to the extent even > > that they can't even keep a civil tongue in his head when posting here. > > You, as do many people, misunderstand the meaning of the "Status" and > "Resolution" fields; a bug does not have to be open to be a legitimate venue > for discussion (bugs which should be silenced are marked as Closed). The > Status reflects precisely that: the current sentiment about the bug. > > That current sentiment is that several senior sysadmins have stated that the > requested change will not be made. Unlike the wiki you are used to, there is a > well-established (if loose) hierarchy within the developers which means that > that decision will not be overturned without their agreement. Now that change > can happen, driven by discussion and progress here, on the mw.org page linked > to in numerous comments above, or elsewhere. It can happen by convincing those > who have already taken a position to rethink it, by convincing other sysadmins > of a similar level, or by convincing higher authorities to overrule them. It > cannot happen by simply reopening the bug and hoping that, if you wish hard > enough, reality will magically readjust. Thank you for the clarification. I wonder if it wouldn't help to post that somewhere, as I suspect that could head off some confusion at the pass. Otherwise, I thoroughly agree with comment 82, and I would also submit that en.wiki is not the best wiki to piss off.
Erik Moeller, and Happy Melon, This is indeed not the place to re-litigate a decision but I strongly insist that there is no case for rediscussion the consensus anyway. 'You' should make a real effort to work together with the Wikipedia community rather than constantly assert and reassert the notion of 'us (the WMF) and 'them' (the volunteers). You are not really listening at all to the 'very different perspective from that of, say, our most active new page patrollers, who will know tons of things from first-hand experience that, at least to the WMF folks who haven't been doing NPP Work recently or ever, aren't obvious at all'. Our most active new page patrollers who know 'tons of things' are a tiny handful of highly experienced editors, admins, and bot operators among the hundreds of new page patrollers who haven't a clue of what they are supposed to be doing, and who furthermore refuse to follow the advice at WP:NPP. That tiny handful, has only been active to exhaustion in order to expose and lay proof to the extremely serious problems with NPP, and seek a solution to it. It is difficult to empathise with the arrogance, rudeness, and single-minded approach demonstrated by some of the WMF employees and/or 'senior' developers on this Bugzilla discussion and it is hardly believable that such behaviour and lack of GF is truly representative of the way the WMF works. They hardly need to be surprised that such patronising comments and incivility has been met with expressions of annoyance and profound dismay from a now seriously disillusioned community, many of whom appear to have far greater insight, dedication, and intelligence than those 'senior' developers and decision makers who might even perceive a salary. Some of the volunteers have now voiced that they may no longer wish to stay around. The 'complex social and technical problems' are a red herring and an attempt to evade the real issues concerning the hurdles, 100s of essays, and walls of text and instruction that have amassed over the years that constitute one of the two main causes for the decline in new registrations and new articles. Anyone following http://meta.wikimedia.org/wiki/Research:Wikimedia_Summer_of_Research_2011 with respect to new page control will conclude that some of its assessments, especially those concerning the work of NPP, and the information that was published at Wikimania, are misplaced - especially those that pretend that 30% of our best contributors began their Wikipedia career as vandals. There appears to have been a complete failure to perceive the distinction between THREE key issues: - Stemming the tide of utterly useless new PAGES that comprise up to 80% of new input; - Encouraging new editors to seek assistance with the creation of new ARTICLES, and providing them with 'easy-edit' solutions - The serious and immediate problem of the trainwreck that the existing method of new page control (NPP) on en.Wiki has become. The 'social' problems are those of a characteristic Wikipedia need to talk endlessly about progress and improvement without actually realising any. The http://www.mediawiki.org/wiki/Article_creation_workflow is another exploit in search of the wrong solutions to the wrong problems, and will take months, if not years, to address the issues. The 'technical' problems are imagined - some Wikis already have far more stringent and complex software solutions for page quality control than those that are requested here. Wiki software is based on an easy programming medium, and most managers of Internet forums and blog software know how to use php and js to customise the user groups and permissions. You are not interested in 'finding a tone of equal partnership ' - you have in fact clearly implied that the broad Wikipedia community has now been disenfranchised. There is obviously no sincere intention of 'working together' - the work that was done by unpaid volunteers, along with their consensus has been summarily dismissed with not even an attempt to understand the background for the proposal. In favouring the rights of the riffraff to go live immediately with uncontroversially inappropriate pages, you will ultimately drive valuable, dedicated maintenance volunteers away from your projects. Wikipedia, on its own admission, has never been a democracy, and if it is to be ruled in future by fiat and no longer by consensus from within the individual projects, it is time for an accredited and trusted senior WMF spokesperson, if not the CEO herself, to make that policy officially public.
(In reply to comment #88) > (In reply to comment #82) > > I've reopened this - it's long from finished. The refusal to conduct this > > trial is based not on 'buckets' of stats, for there aren't any. It's based > > on some 'stats' of extremely dubious provenance that were made up and > > published at Wikimedia. The refusal to allow this trial is not based on a > > decision of the WMF, it's a unilateral decision by one or two single-minded > > WMF staffers whose paid status has gone to their heads - to the extent even > > that they can't even keep a civil tongue in his head when posting here. > > You, as do many people, misunderstand the meaning of the "Status" and > "Resolution" fields; a bug does not have to be open to be a legitimate venue > for discussion (bugs which should be silenced are marked as Closed). The > Status reflects precisely that: the current sentiment about the bug. > > That current sentiment is that several senior sysadmins have stated that the > requested change will not be made. Unlike the wiki you are used to, there is a > well-established (if loose) hierarchy within the developers which means that > that decision will not be overturned without their agreement. Now that change > can happen, driven by discussion and progress here, on the mw.org page linked > to in numerous comments above, or elsewhere. It can happen by convincing those > who have already taken a position to rethink it, by convincing other sysadmins > of a similar level, or by convincing higher authorities to overrule them. It > cannot happen by simply reopening the bug and hoping that, if you wish hard > enough, reality will magically readjust. I certainly do not mistake the patronising tones and incivility from the WMF and/or deveoper side that have been preponderant throughout this discussion.
I too share the sentiments echoed in the above two comments.
(In reply to comment #90) > Erik Moeller, and Happy Melon, > This is indeed not the place to re-litigate a decision but I strongly > insist that there is no case for rediscussion the consensus anyway. 'You' > should > make a real effort to work together with the Wikipedia community rather > than constantly assert and reassert the notion of 'us (the WMF) and 'them' > (the volunteers). I'm an enwiki administrator, functionary and contributor with thirty thousand edits; and a volunteer MediaWiki developer who doesn't and never has taken payment or direction from WMF. Eric is VP of Engineering and WMF Deputy Director. You could not have chosen two people *less* comparable to claim share an "us and them" mentality. The people who have responded to this bug fall right across the spectrum from volunteer developers like myself through to senior staff members. They do not form an "us" in any meaningful sense of the word. On the other hand, there *is* a separation of *cultures* here, and it's something that an awful lot of members of the wiki communities do not appreciate. The developers and (separately) the sysadmins/WMF form their own separate communities with their own goals and practices; and those goals and practices, while closely matching those of enwiki or whereverwiki, do not necessarily precisely align. There is nothing unrealistic, or wrong, with enwiki having goals which are very slightly different from those of the WMF as a whole, or for their requests to not be ones that the Foundation feels bests fits with their own strategies. Think of the developers, and separately the sysadmins (although there is more crossover between those two groups than there usually is between two wiki communities), in exactly the same way you would think of the Wikimedia Commons community. Most WMF wikis have a strong and healthy symbiotic relationship with Commons, and the Commons community generally does a fairly good job of balancing the needs of the many wikis it supports. But the relationship between enwiki and commons is certainly not without its moments of tension, and sometimes the enwiki community does not feel that it is getting everything it would like. But there is an instinctive recognition throughout the community that enwiki has no 'right' to expect any more cooperation than it gets, because Commons is its own project with its own values, and that they will have to convince Commons that whatever it is that they want to do is in the best interests of *both* projects, in order to progress. If you treat the community of developers and sysadmins in the same way, you'll understand the situation much better.
(In reply to comment #93) > (In reply to comment #90) > > Erik Moeller, and Happy Melon, > > This is indeed not the place to re-litigate a decision but I strongly > > insist that there is no case for rediscussion the consensus anyway. 'You' > > should > > make a real effort to work together with the Wikipedia community rather > > than constantly assert and reassert the notion of 'us (the WMF) and 'them' > > (the volunteers). > > I'm an enwiki administrator, functionary and contributor with thirty thousand > edits; and a volunteer MediaWiki developer who doesn't and never has taken > payment or direction from WMF. Eric is VP of Engineering and WMF Deputy > Director. You could not have chosen two people *less* comparable to claim > share an "us and them" mentality. The people who have responded to this bug > fall right across the spectrum from volunteer developers like myself through to > senior staff members. They do not form an "us" in any meaningful sense of the > word. > > On the other hand, there *is* a separation of *cultures* here, and it's > something that an awful lot of members of the wiki communities do not > appreciate. The developers and (separately) the sysadmins/WMF form their own > separate communities with their own goals and practices; and those goals and > practices, while closely matching those of enwiki or whereverwiki, do not > necessarily precisely align. There is nothing unrealistic, or wrong, with > enwiki having goals which are very slightly different from those of the WMF as > a whole, or for their requests to not be ones that the Foundation feels bests > fits with their own strategies. > > Think of the developers, and separately the sysadmins (although there is more > crossover between those two groups than there usually is between two wiki > communities), in exactly the same way you would think of the Wikimedia Commons > community. Most WMF wikis have a strong and healthy symbiotic relationship > with Commons, and the Commons community generally does a fairly good job of > balancing the needs of the many wikis it supports. But the relationship > between enwiki and commons is certainly not without its moments of tension, and > sometimes the enwiki community does not feel that it is getting everything it > would like. But there is an instinctive recognition throughout the community > that enwiki has no 'right' to expect any more cooperation than it gets, because > Commons is its own project with its own values, and that they will have to > convince Commons that whatever it is that they want to do is in the best > interests of *both* projects, in order to progress. If you treat the community > of developers and sysadmins in the same way, you'll understand the situation > much better. I'm not quite sure the two are congruous, for this reason. If I'm looking for something over at Commons, the consensus will come from a project of volunteers similar to myself- I am here entirely of my freewill and not getting paid anything (and I'm quite happy to do it), as are those who work there. I've had ideas shot down by the en.wiki community of volunteers before, and I don't greatly mind it because reasonable people can disagree. Conversely, here the consensus is not being driven by people who see it through the same lens as an unpaid volunteer- it's staffers, who we've said above do not seem to have the same vast experience as we do. Furthermore, I know when I'm being patronized, as it has happened to me innumerable times in my 21 years of living (it goes with having PDD-NOS but still being able to have a coherent conversation); I have been above. I can't say it's easy for me to hear someone tell me to approach their idea with an open mind after they have attempted to filibuster my own to death in spite of all the logical reasons that were given. So yes, there is a certain level of frustration from us.
(In reply to comment #94) > (In reply to comment #93) > > (In reply to comment #90) > > > Erik Moeller, and Happy Melon, > > > This is indeed not the place to re-litigate a decision but I strongly > > > insist that there is no case for rediscussion the consensus anyway. 'You' > > > should > > > make a real effort to work together with the Wikipedia community rather > > > than constantly assert and reassert the notion of 'us (the WMF) and 'them' > > > (the volunteers). > > > > I'm an enwiki administrator, functionary and contributor with thirty thousand > > edits; and a volunteer MediaWiki developer who doesn't and never has taken > > payment or direction from WMF. Eric is VP of Engineering and WMF Deputy > > Director. You could not have chosen two people *less* comparable to claim > > share an "us and them" mentality. The people who have responded to this bug > > fall right across the spectrum from volunteer developers like myself through to > > senior staff members. They do not form an "us" in any meaningful sense of the > > word. > > > > On the other hand, there *is* a separation of *cultures* here, and it's > > something that an awful lot of members of the wiki communities do not > > appreciate. The developers and (separately) the sysadmins/WMF form their own > > separate communities with their own goals and practices; and those goals and > > practices, while closely matching those of enwiki or whereverwiki, do not > > necessarily precisely align. There is nothing unrealistic, or wrong, with > > enwiki having goals which are very slightly different from those of the WMF as > > a whole, or for their requests to not be ones that the Foundation feels bests > > fits with their own strategies. > > > > Think of the developers, and separately the sysadmins (although there is more > > crossover between those two groups than there usually is between two wiki > > communities), in exactly the same way you would think of the Wikimedia Commons > > community. Most WMF wikis have a strong and healthy symbiotic relationship > > with Commons, and the Commons community generally does a fairly good job of > > balancing the needs of the many wikis it supports. But the relationship > > between enwiki and commons is certainly not without its moments of tension, and > > sometimes the enwiki community does not feel that it is getting everything it > > would like. But there is an instinctive recognition throughout the community > > that enwiki has no 'right' to expect any more cooperation than it gets, because > > Commons is its own project with its own values, and that they will have to > > convince Commons that whatever it is that they want to do is in the best > > interests of *both* projects, in order to progress. If you treat the community > > of developers and sysadmins in the same way, you'll understand the situation > > much better. > > I'm not quite sure the two are congruous, for this reason. If I'm looking for > something over at Commons, the consensus will come from a project of volunteers > similar to myself- I am here entirely of my freewill and not getting paid > anything (and I'm quite happy to do it), as are those who work there. I've had > ideas shot down by the en.wiki community of volunteers before, and I don't > greatly mind it because reasonable people can disagree. Conversely, here the > consensus is not being driven by people who see it through the same lens as an > unpaid volunteer- it's staffers, who we've said above do not seem to have the > same vast experience as we do. > > Furthermore, I know when I'm being patronized, as it has happened to me > innumerable times in my 21 years of living (it goes with having PDD-NOS but > still being able to have a coherent conversation); I have been above. I can't > say it's easy for me to hear someone tell me to approach their idea with an > open mind after they have attempted to filibuster my own to death in spite of > all the logical reasons that were given. So yes, there is a certain level of > frustration from us. I've been doing volunteer software development on MediaWiki since 2004 (my first patch was to 1.3.7). I haven't worked for the foundation since about a year and a half ago. I'm rabidly pro-community. I also have views that often greatly differ from the foundation's views as well. I'm not taking the stance I am because I'm with the foundation. I have these views as a volunteer as well (and yes, I still do volunteer work). Btw, before you check, I always edit anon (which funny enough, means I get reverted most of the time). The majority of people from the foundation are/were volunteers. This isn't a us vs them thing, it's an us vs us thing. We should all take a deep breath, and calm down a little. We are at an impasse, and getting livid about it isn't going to help.
(In reply to comment #94) ---->8 [SNIP] 8<---- > Furthermore, I know when I'm being patronized, as it has happened to me > innumerable times in my 21 years of living (it goes with having PDD-NOS but > still being able to have a coherent conversation); I have been above. I'm not sure how much I can impress upon you that you are most decidedly *not* being patronized. If anything, quite the opposite: this issue has been assigned a significant amount of resources within the Foundation (in fact, it's pretty much my "go to" task right now). It is possible that you're experiencing a disconnect between the "culture" of Wikipedia and the "culture" of development. Developers, programmers, designers - we tend to be a bit harsh in our language from time to time, and make comments that can appear to be hostile or patronizing. However, they're *not* - these comments are simply direct, and meant to be taken both at face value and with some self-deprecating humor. I can tell you for true that this issue has been near the forefront of our talks for the past several weeks, and the primary focus of conversation for the past week or so, and I expect it will remain at that volume for the next several weeks (possibly months). If we were patronizing you, there would have been simple pat on the head and nothing more. Instead, your issues have taken center stage and we are actively working on ways in which we can learn more about the way that *you* do your job and ways that we can *make it better*. So please, seriously, engage with us on the Mediawiki page. We're trying to set up an easy system for you to be able to show us exactly how *you* do NPP (everyone is different, and we want to have as much data as possible to work with). I, for one, am very excited to work on this series of problems. They're hard problems, which makes them extremely interesting to me - which means that I'm going to latch onto them like a pit bull. I know that won't mean much to you right now (you don't trust anything I have to say), but if you ask around you'll find that people who know me and have worked with me will tell you that if I think something is worth fighting for, I'll fight to the end for it. And this, I think, is worth fighting for.
Sorry to interrupt but I think such problem can be solved by abuse filter. Such trial can be made by setting this filter for non-autoconfirmed users. Regards
(In reply to comment #97) > Sorry to interrupt but I think such problem can be solved by abuse filter. Such > trial can be made by setting this filter for non-autoconfirmed users. Such change can be easily undone by WMF staff.
(In reply to comment #98) > (In reply to comment #97) > > Sorry to interrupt but I think such problem can be solved by abuse filter. Such > > trial can be made by setting this filter for non-autoconfirmed users. > > Such change can be easily undone by WMF staff. My Intent was to fix this problem by setting of abusefilter rather than changing shell setting for en Wiki. It is not even required to file such bug in Bugzilla for such requirement.
(In reply to comment #99) > (In reply to comment #98) > > (In reply to comment #97) > > > Sorry to interrupt but I think such problem can be solved by abuse filter. Such > > > trial can be made by setting this filter for non-autoconfirmed users. > > > > Such change can be easily undone by WMF staff. > > My Intent was to fix this problem by setting of abusefilter rather than > changing shell setting for en Wiki. It is not even required to file such bug in > Bugzilla for such requirement. It could hit the threshold, and anyway such an action would be worth an emergency deflag by whoever has the ability to perform it.
(In reply to comment #97) > Sorry to interrupt but I think such problem can be solved by abuse filter. Such > trial can be made by setting this filter for non-autoconfirmed users. As Nemo_bis says, there are hard cutoff limits in the AbuseFilter code that limit the maximum percentage of edits that can trip filters (around 1-2%, if memory serves). A filter to implement this logic would be unreliable because it has a reasonable likelihood of reaching that limit.
So... The WMF has spat in the face of consensus... Now what?
If you want to see how the WMF is attempting to help the community achieve its goals, see http://www.mediawiki.org/wiki/Page_Triage as well as http://www.mediawiki.org/wiki/Category:Article_Creation_Workflow
(In reply to comment #103) > If you want to see how the WMF is attempting to help the community achieve its > goals, see http://www.mediawiki.org/wiki/Page_Triage as well as > http://www.mediawiki.org/wiki/Category:Article_Creation_Workflow Mark, if you really want to see how the WMF has 'attempted to help the community', perhaps you could read this entire bug from start to finish, take note that a full 8 months further on very little has actually transpired. A further community effort - an NPP survey launched in fact by some of those above who were vehemently dissatisfied by the result of this bug, but with the best of intentions, was also met by a largely unexplained exclusion of the volunteer research team from its evaluation - and that now only very recently, the Article Creation Flow and NPP Triage projects have been relaunched by the WMF ostensibly as 'new' projects. The end effect has been, instead of looking for ways to enhance new-user retentions, the community vs. WMF gap has in fact widened, and Wikipedia has lost the collaboration of dedicated users and admins - especially those experienced in NPP matters - some of whom may even have retired or semi-retired from Wikipedia as a result.
I'm sorry, but that's factually incorrect. Nobody was excluded. The WMF wrote a report, but provided the full data to the research team. We've offered multiple times to provide any further data requested. Nobody has ever requested. Nobody was excluded.
(In reply to comment #105) > I'm sorry, but that's factually incorrect. Nobody was excluded. The WMF wrote > a report, but provided the full data to the research team. We've offered > multiple times to provide any further data requested. Nobody has ever > requested. Nobody was excluded. Th
(In reply to comment #106) > (In reply to comment #105) > > I'm sorry, but that's factually incorrect. Nobody was excluded. The WMF wrote > > a report, but provided the full data to the research team. We've offered > > multiple times to provide any further data requested. Nobody has ever > > requested. Nobody was excluded. > > That report, published nearly five months after the survey closed, was the first coherent form of data that was issued to anyone in a form that could be used. The WMF report preempted any effort that the research team would have made, aThe volunteer research team was never supplied with the original data extractions that were requested from the WMF. The WMF was asked to provide legal, technical (a survey software solution), and some math extrapolations. The next thing the volunteer team knew was that the WMF had published a complete summary and its interpretation of the survey results. The original research team was not involved in any way at all with the elaboration of this report and was not invited to collaborate on it. Among other reasons, the delays were explained as being due to contractors being overworked, lack of funds, and other developmental priorities.
I'm summarizing your comment here to make sure I understand your issues: --- BEGIN SUMMARY --- (In reply to comment #107) > That report, published nearly five months after the survey closed, was the > first coherent form of data that was issued to anyone in a form that > could be used. The WMF was slow. > The WMF report preempted any effort that the research team would have > made, The report, when it did come out, made others -- who may have been interested in doing their own research -- feel like it wasn't necessary. > The volunteer research team was never supplied with the original data > extractions that were requested from the WMF. Anyone who still wanted to do any research wasn't given the data. > The WMF was asked to provide legal, technical (a survey software solution), > and some math extrapolations. The next thing the volunteer team knew was > that the WMF had published a complete summary and its interpretation of the > survey results. Instead of immediately giving the volunteer team the resources and data they asked for -- so the volunteers could form their own conclusions -- the WMF went ahead and published its own opinion. > The original research team was not involved in any way > at all with the elaboration of this report and was not invited to > collaborate on it. Among other reasons, the delays were explained as being > due to contractors being overworked, lack of funds, and other > developmental priorities. The explanation the WMF offered reflected the reality of the limited resources a non-profit has. Conveniently, from your point of view, this reality allowed the WMF to publish its opinion without community input. --- END SUMMARY --- Is this an accurate representation of the assertions you're making? How do you reconcile this with Philippe's statement that (in comment #105): > The WMF wrote a report, but provided the full data to the research team. > We've offered multiple times to provide any further data requested. Nobody > has ever requested. Specifically, you state: > The volunteer research team was never supplied with the original data > extractions that were requested from the WMF. Perhaps they were satisfied with the "full data" that Philippe mentions? (The difference between this and the "original data extractions" that you mention is not clear to me.)
