Brion Vibber wrote: And manual approval. 'niceuser' suddenly renaming itself to "Brion is a ***" is not good. And bureaucrats being throttled so it can't be unrenamed worse. (And worst if it's a legitimate account which has been compromised)

Andrew Garrett wrote: Which would make it significantly more disruptive... -- Alex (wikipedia:en:User:Mr.Z-man)

On Sun, Apr 5, 2009 at 9:49 AM, Charlotte Webb <charlottethewebb(a)gmail.com> wrote: There's still the "Why can't I log in anymore?" problem. Sysops can currently block people, but at least they're told that they blocked, who blocked them, and why.

On Fri, Apr 3, 2009 at 2:30 AM, Brion Vibber <brion(a)wikimedia.org> wrote: I believe the immediate motivation for MZMcBride's request is actually a discussion on enwiki that there weren't enough trusted individuals to forcibly rename accounts containing sensitive information in their username. If that is the goal, then a self-renaming function would not address it. To be honest, I don't really understand why one would use renaming over revision delete to hide bad account names, but some ArbCom members and similarly highly placed persons have stated that there are circumstances where renaming is currently preferred over revision delete. -Robert Rohde

On Fri, Apr 3, 2009 at 12:01 PM, Robert Rohde <rarohde(a)gmail.com> wrote: I think Domas might have objections if the number of renames suddenly increased by a factor of 10, actually. He's complained about them before. They have to update an awful lot of rows. In principle, yes. Of course they can get stuck half-done, and if you rename someone twice in quick succession I don't know what will happen with the job queue. Renaming is not currently a simple operation, because of our schema. We encode the username all over the place. If it were just in the user table, renaming would be less of a big deal, since we'd change one row plus maybe some stuff in RC. But we have to change a ton of rows in a ton of tables, almost all of which (for long-established users) will be cold and so will be dug out from disk. So we have to defer things, so they can be in a half-finished state, so it's slow and messy. Also keep in mind that if someone is renamed without their knowledge, they'll be unable to log into their account. The error message will only say that the user doesn't exist, or -- if a user is created with the same name -- it will just tell them their password is wrong! Forcible renames are scary for this reason as well.

On Fri, Apr 3, 2009 at 1:18 PM, Jan Luca <jan(a)jans-seite.de> wrote: This is an okay place. You'll want to provide your public key, desired commit name, and what you want to use the commit access for.

Hello, when will there a answer? Gruß Jan Luca -----Ursprüngliche Nachricht----- Von: wikitech-l-bounces(a)lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] Im Auftrag von Jan Luca Gesendet: Freitag, 3. April 2009 19:58 An: 'Wikimedia developers' Betreff: Re: [Wikitech-l] Commit access Hello, Key: http://toolserver.org/~jan/files/SSH2-RSA.pub Commit name: jan Alternative: jan_luca I will use my commit access for commit extensions. At the moment I create a extensions for my poll-script on Wikimedia Toolserver. Viele Grüße Jan -----Ursprüngliche Nachricht----- Von: wikitech-l-bounces(a)lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] Im Auftrag von Aryeh Gregor Gesendet: Freitag, 3. April 2009 19:22 An: Wikimedia developers Betreff: Re: [Wikitech-l] Commit access On Fri, Apr 3, 2009 at 1:18 PM, Jan Luca <jan(a)jans-seite.de> wrote: This is an okay place. You'll want to provide your public key, desired commit name, and what you want to use the commit access for. _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Aryeh Gregor wrote: Any reason for not displaying an excerpt from the rename log for that user on login failure, much like on editing deleted pages?

On Fri, Apr 3, 2009 at 9:51 AM, Aryeh Gregor <Simetrical+wikilist@gmail.com<Simetrical%2Bwikilist@gmail.com> > On Fri, Apr 3, 2009 at 12:01 PM, Robert Rohde &lt;rarohde(a)gmail.com> > That said, I'm also not sure why we couldn't trust sysops with this. > > Assuming the limitation is not technical (i.e. the servers won't > > explode) > > I think Domas might have objections if the number of renames suddenly > increased by a factor of 10, actually. He's complained about them > before. They have to update an awful lot of rows. > > > and renames are undoable (they are right?) > > In principle, yes. Of course they can get stuck half-done, and if you > rename someone twice in quick succession I don't know what will happen > with the job queue. > > Renaming is not currently a simple operation, because of our schema. > We encode the username all over the place. If it were just in the > user table, renaming would be less of a big deal, since we'd change > one row plus maybe some stuff in RC. But we have to change a ton of > rows in a ton of tables, almost all of which (for long-established > users) will be cold and so will be dug out from disk. So we have to > defer things, so they can be in a half-finished state, so it's slow > and messy. > > Also keep in mind that if someone is renamed without their knowledge, > they'll be unable to log into their account. The error message will > only say that the user doesn't exist, or -- if a user is created with > the same name -- it will just tell them their password is wrong! > Forcible renames are scary for this reason as well. I agree that admins might not be necessarily trusted with permissions which would screw up site operations. We do no administrator ID verification, and the length and breadth of high load website operations/architecture experience is not a selection criteria. Limiting it to people who understand what effects it could have, and who are better known to the community/foundation, seems sensible. Any reason not to set this up as a new userright we can have Arbcom hand to admins on request/review/background verification? We already have them as a mechanism to extend admin rights to CU. This is less sensitive than that - but we don't have any mechanism in place to handle anything between "admins can add themselves to this" and CU right now. OTRS might sorta count there, but it's sideways of the on-wiki administrative structure. -- -george william herbert george.herbert(a)gmail.com