Wikimedia Bugzilla is closed!

I do not see any consensus in that discussion. It had a very limited number of participants. I had trouble imagining how so few people can just ban many tens thousands of users from creating accounts. This proposal is just another version of [[bugzilla:30208]] and should follow its way.

Indeed.

-shell for the moment till this is dealt with properly

(In reply to comment #1)
> I do not see any consensus in that discussion. It had a very limited number of
> participants.
It was advertised, I'm sure I even saw it on CENT, the Global en.wiki template for listing RfCs. 

> I had trouble imagining how so few people can just ban many tens
> thousands of users from creating accounts.
I'm going to take it you didn't read it properly or even just the closing admins notes? This proposal is to stop people who have a user account but not the autoconfirmed bit ([[WP:AUTOCONFIRMED]]) from creating even more accounts.

> This proposal is just another version of [[bugzilla:30208]] and should follow its way.
I'm failing to see the correlation between someone that has a user account that does't already have auto-confirmed status stopping them from creating even more user accounts whilst LOGGED IN and preventing them from creating accounts. Perhaps you could point me in direction about that?

(In reply to comment #1)
> I had trouble imagining how so few people can just ban many tens
> thousands of users from creating accounts. 

As p858snake said, this is wrong. Please read the entire section on WP:VPR carefully before commenting.

(In reply to comment #2)
> -shell for the moment till this is dealt with properly

Probably more discussion is needed, I agree.

(In reply to comment #1)
> I do not see any consensus in that discussion. It had a very limited number of
> participants. I had trouble imagining how so few people can just ban many tens
> thousands of users from creating accounts. This proposal is just another
> version of [[bugzilla:30208]] and should follow its way.

It is in no way the same thing, and should absolutely NOT follow the course it did; why don't you check the Signpost for September 26th to see how people reacted to that?  I don't greatly care if this gets implemented or not (though I supported it), but to conflate the two is extremely misleading.  I also think This, that and the other makes good points.

Is there any update on that or should we abandon this bug report ?

The RfC premise looks wrong to me.

There are logs both for user to children accounts
http://en.wikipedia.org/w/index.php?title=Special%3ALog&user=Little+Red+Corvette+Guy

and for children accounts linking them to the parent one
http://en.wikipedia.org/w/index.php?title=Special%3ALog&page=User%3AMr.+Playbill


That can be done even with no checkuser rights. I think that this bug should be wontfixed and a new enhacement opened to checkuser extension with wherever they want the relationship to appear.

(In reply to comment #7)
> The RfC premise looks wrong to me.
> 
> There are logs both for user to children accounts
> http://en.wikipedia.org/w/index.php?title=Special%3ALog&user=Little+Red+Corvette+Guy
> 
> and for children accounts linking them to the parent one
> http://en.wikipedia.org/w/index.php?title=Special%3ALog&page=User%3AMr.+Playbill
> 
> 
> That can be done even with no checkuser rights. I think that this bug should be
> wontfixed and a new enhacement opened to checkuser extension with wherever they
> want the relationship to appear.

If the premise looks wrong to you, it's because you're misunderstanding it.  We're trying to prevent him (and others, but mostly him) from being able to create 6 accounts and create that much more annoyance for the people cleaning up after him.  We all know when it's him, that's not the issue; the issue is that he's creating ~300% more of a mess than he'd be able to if this was implemented.

Sorry, I was looking at the opening comment of the RFC, not at the outcome.

(In reply to comment #9)
> Sorry, I was looking at the opening comment of the RFC, not at the outcome.

Looking over it again, I can't blame you; there was some initial confusion over what we were looking for.  Thankfully, the eventual outcome is clearer.

So do we get now that new limitation?

looks like this wasn't implemented yet.

The Wikimedia configuration files are in Git now. So someone needs to commit a proposed changeset and then asked for it to be merged into the master, or something, I believe.

So it looks like you'd want to commit a change to this repo: <https://gerrit.wikimedia.org/r/gitweb?p=operations/mediawiki-config.git>.

Specifically, it's in wmf-config/InitialiseSettings.php (<https://gerrit.wikimedia.org/r/gitweb?p=operations/mediawiki-config.git;a=blob;f=wmf-config/InitialiseSettings.php;h=4e4a9bc0efd0718d00aa47018eff910177eee116;hb=ffd469239a80b8bb9813eb029e4cd71a3ea52db9>):

---
'wgAccountCreationThrottle' => array(
        'he' => 4,
        'default' => 6, // previously 10
        'private' => 0, // disable for wikis with sysop-only account creation
        'fishbowl' => 0,
        'idwiki' => 0,
        'swwiki' => 150, // for event 2011-11-30, contact User:Ijon -- TS
),
---

Pretty sure it should be done in wmf-config/throttle.php now.

No, wgAccountCreationThrottle is still at InitialiseSettings.php

We don't have a configuration for changing to just registered users non-autoconfirmed. Sysops are throttle-skipped, and the rest confined by $wgAccountCreationThrottle.

I changed the product/component: the feature we are requesting doesn't appear to exist in MediaWiki yet, so shell can't do anything.

I don't think enwiki requires this feature anymore; the editfiltermanagers are using an edit filter to collect relevant data. However, since I moved the component to MediaWiki, the bug is still technically valid. I'll leave it up to others to decide whether this is a useful feature to add to MW core.