Last modified: 2013-01-31 15:38:02 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 30208 - Trial for restricting non-autoconfirmed users from creating new articles on enwiki
Trial for restricting non-autoconfirmed users from creating new articles on e...
Status: RESOLVED WONTFIX
Product: Wikimedia
Classification: Unclassified
Site requests (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/wiki/Wikipedi...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-03 22:53 UTC by Snottywong
Modified: 2013-01-31 15:38 UTC (History)
26 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Snottywong 2011-08-03 22:53:43 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).
Comment 1 Max Semenik 2011-08-04 04:20:01 UTC
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?
Comment 2 Snottywong 2011-08-04 14:08:33 UTC
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.
Comment 3 Brion Vibber 2011-08-04 16:51:24 UTC
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!)
Comment 4 Snottywong 2011-08-04 17:14:33 UTC
(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"?
Comment 5 Snottywong 2011-08-04 17:42:08 UTC
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.
Comment 6 Snottywong 2011-08-04 19:40:36 UTC
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.
Comment 7 Chad H. 2011-08-04 19:48:43 UTC
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.
Comment 8 Snottywong 2011-08-04 22:14:56 UTC
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?
Comment 9 cs 2011-08-04 22:32:51 UTC
(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.
Comment 10 Snottywong 2011-08-04 23:50:58 UTC
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.
Comment 11 cs 2011-08-05 00:15:43 UTC
(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.
Comment 12 The Blade of the Northern Lights 2011-08-05 01:00:15 UTC
(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.
Comment 13 Brandon Harris 2011-08-05 06:24:46 UTC
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.
Comment 14 The Blade of the Northern Lights 2011-08-05 06:36:48 UTC
(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.
Comment 15 Brandon Harris 2011-08-05 11:30:33 UTC
Note to shell users:  This bug is controversial; please do not implement at this time.
Comment 16 Snottywong 2011-08-05 14:16:42 UTC
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).
Comment 17 Chad H. 2011-08-05 14:51:24 UTC
(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?
Comment 18 The Blade of the Northern Lights 2011-08-05 15:23:29 UTC
(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.
Comment 19 cs 2011-08-05 18:32:32 UTC
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.
Comment 20 Ryan Lane 2011-08-05 18:55:31 UTC
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.
Comment 21 James F. 2011-08-05 20:52:44 UTC
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.
Comment 22 James Alexander 2011-08-06 06:10:20 UTC
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.
Comment 23 Max Semenik 2011-08-06 06:12:33 UTC
(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.
Comment 24 Philippe Beaudette 2011-08-06 06:16:54 UTC
(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
Comment 25 James Alexander 2011-08-06 06:35:40 UTC
(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.
Comment 26 Max Semenik 2011-08-06 07:38:25 UTC
(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.
Comment 27 Snottywong 2011-08-09 00:42:57 UTC
(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.
Comment 28 Snottywong 2011-08-09 00:46:07 UTC
(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.
Comment 29 Brandon Harris 2011-08-09 06:41:26 UTC
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.
Comment 30 Snottywong 2011-08-09 06:55:58 UTC
(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?
Comment 31 Brandon Harris 2011-08-09 07:05:30 UTC
(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
Comment 32 MZMcBride 2011-08-09 07:47:44 UTC
(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.
Comment 33 Ariel T. Glenn 2011-08-09 08:43:41 UTC
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.
Comment 34 Snottywong 2011-08-09 14:40:37 UTC
(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.
Comment 35 The Blade of the Northern Lights 2011-08-09 15:47:29 UTC
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.
Comment 36 Ryan Lane 2011-08-09 16:56:50 UTC
(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.
Comment 37 Aaron Schulz 2011-08-09 17:18:13 UTC
(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.
Comment 38 Rob Lanphier 2011-08-09 18:47:09 UTC
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!
Comment 39 The Blade of the Northern Lights 2011-08-09 20:22:06 UTC
(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.
Comment 40 Snottywong 2011-08-09 21:57:20 UTC
(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.
Comment 41 Snottywong 2011-08-12 00:20:11 UTC
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
Comment 42 The Blade of the Northern Lights 2011-08-16 00:53:03 UTC
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.
Comment 43 Erik Moeller 2011-09-14 01:50:31 UTC
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
Comment 44 The Blade of the Northern Lights 2011-09-14 02:47:45 UTC
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?
Comment 45 Snottywong 2011-09-14 03:52:17 UTC
(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.
Comment 46 Philippe Beaudette 2011-09-14 03:57:52 UTC
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.
Comment 47 The Blade of the Northern Lights 2011-09-14 04:59:10 UTC
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.
Comment 48 Snottywong 2011-09-14 05:54:20 UTC
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.
Comment 49 James Alexander 2011-09-14 06:59:04 UTC
<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).
Comment 50 James Alexander 2011-09-14 07:00:58 UTC
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)
Comment 51 Nemo 2011-09-14 07:03:40 UTC
(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).
Comment 52 Roan Kattouw 2011-09-14 11:46:34 UTC
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.
Comment 53 cs 2011-09-14 13:19:32 UTC
(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?
Comment 54 Roan Kattouw 2011-09-14 13:24:25 UTC
(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.
Comment 55 cs 2011-09-14 13:53:58 UTC
(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.
Comment 56 cs 2011-09-14 14:14:05 UTC
(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.
Comment 57 cs 2011-09-14 16:11:43 UTC
(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.
Comment 58 Snottywong 2011-09-14 17:03:55 UTC
(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.
Comment 59 Erik Moeller 2011-09-14 17:05:48 UTC
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
Comment 60 The Blade of the Northern Lights 2011-09-14 17:28:12 UTC
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.
Comment 61 Roan Kattouw 2011-09-14 17:56:20 UTC
(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.
Comment 62 Snottywong 2011-09-14 18:30:13 UTC
(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.
Comment 63 The Blade of the Northern Lights 2011-09-14 18:38:03 UTC
(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.
Comment 64 Steven Walling 2011-09-14 18:55:14 UTC
(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.
Comment 65 Platonides 2011-09-14 20:54:23 UTC
(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).
Comment 66 Brandon Harris 2011-09-14 21:00:02 UTC
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.
Comment 67 Ryan Lane 2011-09-14 21:11:19 UTC
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.
Comment 68 The Blade of the Northern Lights 2011-09-14 21:29:15 UTC
(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.
Comment 69 Brandon Harris 2011-09-14 21:31:54 UTC
(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?
Comment 70 Ryan Lane 2011-09-14 21:36:37 UTC
(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.
Comment 71 The Blade of the Northern Lights 2011-09-14 21:39:47 UTC
(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.
Comment 72 Nemo 2011-09-14 21:49:11 UTC
(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.
Comment 73 The Blade of the Northern Lights 2011-09-14 21:51:49 UTC
(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.
Comment 74 Snottywong 2011-09-14 21:58:02 UTC
(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.
Comment 75 James Alexander 2011-09-14 22:03:39 UTC
(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.
Comment 76 Brandon Harris 2011-09-14 22:07:05 UTC
(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.
Comment 77 Brandon Harris 2011-09-14 22:10:30 UTC
(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.
Comment 78 Ryan Lane 2011-09-14 22:11:15 UTC
(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.
Comment 79 Platonides 2011-09-15 19:39:25 UTC
(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.
Comment 80 The Blade of the Northern Lights 2011-09-15 19:46:30 UTC
(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.
Comment 81 cs 2011-09-16 07:40:36 UTC
(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.
Comment 82 cs 2011-09-16 07:57:57 UTC
(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?
Comment 83 cs 2011-09-16 08:02:34 UTC
(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.
Comment 84 cs 2011-09-16 08:10:24 UTC
(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.
Comment 85 cs 2011-09-16 08:14:07 UTC
(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.
Comment 86 Erik Moeller 2011-09-16 09:37:40 UTC
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.
Comment 87 aaron.adrignola 2011-09-16 14:09:09 UTC
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.
Comment 88 Happy-melon 2011-09-16 18:27:08 UTC
(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.
Comment 89 The Blade of the Northern Lights 2011-09-16 18:34:11 UTC
(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.
Comment 90 cs 2011-09-16 21:51:31 UTC
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.
Comment 91 cs 2011-09-16 23:35:39 UTC
(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.
Comment 92 The Blade of the Northern Lights 2011-09-16 23:44:08 UTC
I too share the sentiments echoed in the above two comments.
Comment 93 Happy-melon 2011-09-16 23:45:07 UTC
(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.
Comment 94 The Blade of the Northern Lights 2011-09-17 00:00:53 UTC
(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.
Comment 95 Ryan Lane 2011-09-17 00:16:50 UTC
(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.
Comment 96 Brandon Harris 2011-09-17 03:43:45 UTC
(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.
Comment 97 Mayur 2011-09-17 15:26:24 UTC
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
Comment 98 Max Semenik 2011-09-17 15:30:07 UTC
(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.
Comment 99 Mayur 2011-09-17 15:36:02 UTC
(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.
Comment 100 Nemo 2011-09-17 15:45:17 UTC
(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.
Comment 101 Happy-melon 2011-09-18 20:34:59 UTC
(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.
Comment 102 barts1a 2012-03-22 01:23:51 UTC
So... The WMF has spat in the face of consensus... Now what?
Comment 103 Mark A. Hershberger 2012-03-22 20:11:51 UTC
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
Comment 104 cs 2012-03-23 01:03:05 UTC
(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.
Comment 105 Philippe Beaudette 2012-03-23 03:22:26 UTC
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.
Comment 106 cs 2012-03-23 06:04:42 UTC
(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
Comment 107 cs 2012-03-23 06:15:28 UTC
(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.
Comment 108 Mark A. Hershberger 2012-03-23 15:27:11 UTC
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.)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links