I have enjoyed the technical discussions around the design of the voting mechanism, and I think it is quite worthwhile for us to continue learning and thinking about these things. There are several tradeoffs here, and the choice is not easy.
But additionally I think we should think about what the purpose of the elections is, and what the appropriate design should be. This should be part of a broader analysis of what the purpose of the board should be, and what the overall design of the process of board selection (including elections, appointments, etc.) should be in order to achieve those goals.
The possibilities open to us are endless. And there are strengths and weaknesses to various approaches.
A quick list of some of the things that I think are important:
1. Diverse representation - and I mean diversity in the sense of geography, languages, projects, gender, skills, etc.
2. Professionalism - part of diversity, we don't want or need all the board to be "good editors" but rather to have as well people who have technical experience, nonprofit governance experience, legal experience, big business experience, dot-com experience, public charity fundraising experience, foundation grant application experience, political experience/contacts, etc.
3. Harmony - the current board is filled with good people who do not always agree but who -- to my great pleasure -- work together in an atmosphere of mutual respect and trust (mostly, we are human of course :) ) -- approval voting is good for this, it generates candidates who have broad support. Some voting systems would be much more likely to allow a "troll candidate" to concentrate attention and get elected in a partisan split, etc.
4. Responsiveness - that the board listens to the community
5. Independence - that the board has the moral authority to make unpopular decisions at times, so that the board does not end up being too beholden to internal politics of the moment and can feel the strength to stick to principles even in cases where those principles might not be so popular
(Yes, 4 and 5 are in tension and therefore have to be balanced.)
--Jimbo
Jimmy Wales wrote:
Responsiveness - that the board listens to the community
Independence - that the board has the moral authority to make
unpopular decisions at times, so that the board does not end up being too beholden to internal politics of the moment and can feel the strength to stick to principles even in cases where those principles might not be so popular
(Yes, 4 and 5 are in tension and therefore have to be balanced.)
These relate, I think, to the question of what exactly the community *is*. The core group of the community are probably people who: 1) are committed to Wikimedia's core goals (though they may disagree on some matters); and 2) spend significant time and effort working towards those goals. But that's a pretty abstract definition, and you can't make voting eligibility based on that too easily. Our current approximation is "people who've edited a Wikimedia project at least a little bit", but that isn't really the same thing. As our projects get more and more popular, an increasing percentage of the total internet population will be eligible to vote under current rules, and "anyone who's ever edited Wikipedia" will start to look less and less like any sort of community. It'd also make us susceptible to outside advertising campaigns, as someone wanting to influence the Foundation would just need to rally some otherwise inactive account-holders to rediscover their accounts and vote.
Some of this can be tackled using human judgment by the Foundation being "responsive" in ways other than through voting. If the Board members are themselves longstanding Wikimedians, then presumably they have some idea of what the community is and how to listen to it, and so can keep an eye on what it thinks without solving all the tricky problems of voting and voter eligibility.
That doesn't really solve the question of how to get people on the board in the first place, of course, which I'll pass on for now.
-Mark
On Jul 14, 2007, at 11:19 AM, Delirium wrote:
These relate, I think, to the question of what exactly the community *is*. The core group of the community are probably people who: 1) are committed to Wikimedia's core goals (though they may disagree on some matters); and 2) spend significant time and effort working towards those goals. But that's a pretty abstract definition, and you can't make voting eligibility based on that too easily. Our current approximation is "people who've edited a Wikimedia project at least a little bit", but that isn't really the same thing. As our projects get more and more popular, an increasing percentage of the total internet population will be eligible to vote under current rules, and "anyone who's ever edited Wikipedia" will start to look less and less like any sort of community. It'd also make us susceptible to outside advertising campaigns, as someone wanting to influence the Foundation would just need to rally some otherwise inactive account-holders to rediscover their accounts and vote.
I agree completely. If we feel there was low turnout in this election, I think one possible solution would be better notification... and this has been discussed extensively already. But *another* thing to think about is whether we have defined voter eligibility much too broadly. I think we mostly do not want the board of the foundation elected by casual users or the general public, but by "the core group of the community" .. which is of course hard to define, but probably means more than just making a small number of edits at some point in time.
--Jimbo
On 7/14/07, Jimmy Wales jwales@wikia.com wrote:
I have enjoyed the technical discussions around the design of the voting mechanism, and I think it is quite worthwhile for us to continue learning and thinking about these things. There are several tradeoffs here, and the choice is not easy.
Aye, true dat.
But additionally I think we should think about what the purpose of the elections is, and what the appropriate design should be. This should be part of a broader analysis of what the purpose of the board should be, and what the overall design of the process of board selection (including elections, appointments, etc.) should be in order to achieve those goals.
The possibilities open to us are endless. And there are strengths and weaknesses to various approaches.
A quick list of some of the things that I think are important:
- Diverse representation - and I mean diversity in the sense of
geography, languages, projects, gender, skills, etc.
Diversity but not tokenization. On this count we have probably done astonishingly well considering what our core demographic is. The board has never been and there is no prospect of it becoming a panel of teenage nerds ;D
Should be noted that even barring the extreme of tokenization there is no need to even strive for perfect "representativeness", diversity is well good enough. In this as most things, the perfect is an enemy of the good. We cannot hope for the board to represent equally tiny trial projects and the established mega-projects in our midst, nor ancient dead languages on a par with english; that way lies madness.
2. Professionalism - part of diversity, we don't want or need all the
board to be "good editors" but rather to have as well people who have technical experience, nonprofit governance experience, legal experience, big business experience, dot-com experience, public charity fundraising experience, foundation grant application experience, political experience/contacts, etc.
Definitely there are at least certain essential skills that the board would ideally encompass within its own makeup rather than have to always rely on consulting experts outside itself. These of course include (1.) understanding of jurisprudence, (2.) financing and handling the
finances of a non-profit and perhaps most improtantly (3.) the ineffable (and not necessarily professional) skills for keeping a group of people like the board working as seamlessly as possible.
Other professional skill-set/experience goodies than the above, would likely fall under the heading of diversity, and something very useful to make the best use of possible, if in no other way than to work those people as conduits to the committees who handle the type of things they are used to working with.
3. Harmony - the current board is filled with good people who do not
always agree but who -- to my great pleasure -- work together in an atmosphere of mutual respect and trust (mostly, we are human of course :) ) -- approval voting is good for this, it generates candidates who have broad support. Some voting systems would be much more likely to allow a "troll candidate" to concentrate attention and get elected in a partisan split, etc.
This is an important point. One of the things that no doubt helps the board so far attain the harmony is that the size of the board has and will continue to grow, so there is no incentive for any infighting for relection to a fixed set of seats, and also the job has as I understand it been largely coping with external pressures, and the need to proceed upon urgent matters. As things solidify, it will be good to find ways to anchor the board in someway, to ensure everlasting continuity in its functions.
Even though this election was the first! time that an election caused a seat to change hands, we need to guard both against the possibility of a troll candidate, but also massive overturn of good candidates with other good candidates. Simply changing too much of the board in one election would be risky. So it is important that we keep to the tranche system. (I have even toyed around with the idea of having a staggered length term system, which would allow for organic expansion of the board, For example, three seats constested, who comes first, serves up to three years (with the option to step down at any election time, and make it the case that there will be two three year seats at stake that time, if there is an other scheduled 3. year termer contesting his seat at that time), both second and third serve normal 2 year terms. Every time there isn't an incumbent 3. year termer contesting, a new seat is added.
This system would grow the board incrementally and at a natural pace, all that would be needed would be to set an upper bound (revisable of course, as experience would dictate) for the board size, without the need to think separately at each election about how much to expand the board if at all.
4. Responsiveness - that the board listens to the community
- Independence - that the board has the moral authority to make
unpopular decisions at times, so that the board does not end up being too beholden to internal politics of the moment and can feel the strength to stick to principles even in cases where those principles might not be so popular
(Yes, 4 and 5 are in tension and therefore have to be balanced.)
--Jimbo
-- Jussi-Ville Heiskanen, ~ [[User:Cimon Avaro]]
On Jul 15, 2007, at 2:24 PM, Jussi-Ville Heiskanen wrote:
Should be noted that even barring the extreme of tokenization there is no need to even strive for perfect "representativeness", diversity is well good enough. In this as most things, the perfect is an enemy of the good. We cannot hope for the board to represent equally tiny trial projects and the established mega-projects in our midst, nor ancient dead languages on a par with english; that way lies madness.
Agreed, and we also do not want board members to think of themselves as "representative of Europe" or "representative of Asia" or "representative of Wiktionary" whose job it is to fight for resources on behalf of that group or project. Rather, all board members should try to be globally inclined in every way as much as possible.
On Sat, Jul 14, 2007 at 11:24:05AM -0700, Jimmy Wales wrote:
I think we mostly do not want the board of the foundation elected by casual users or the general public, but by "the core group of the community" .
This could be a bit of a problem, since I have a feeling that several dedicated community members were excluded this time around. In the case of some well known community members (like for instance Jan-Bart iirc), this got corrected. But as always in such cases, it might be wise to investigate a little further, you know, just in case you're looking at the tip of an iceberg you didn't know was there.
Perhaps a poll along the lines of "I feel like I'm a member of the community, but nevertheless was not allowed to vote" would be useful?
sincerely, Kim Bruning
On 7/18/07, Kim Bruning kim@bruning.xs4all.nl wrote:
Perhaps a poll along the lines of "I feel like I'm a member of the community, but nevertheless was not allowed to vote" would be useful?
Interesting, I personally think however this kind of question is better to solve based on intersubjective opinions rather than self-estimations of each individual (they should be enable to vote vs I should be able to vote)
As long as minimum subjective line of our community member's involvement sense matter, I think we don't need a new poll. Allow anons to vote. Period. Since 2005 the lowest claimed threshould I have ever seen claimed came from unregistered users. I don't mean we should do that, I rather would like to say self-satisfaction might not be a good measure to decide threshold. I personally find it unwelcome so we need another measure, not subjective opinions of each individuals if he deserves voting eligibility.
Also I remember a user who claimed 400 edits was too high requirement and contradict with his or her self-estimation of involvement (he or she said to make one or two edits per day and believed for the sake of constant commitment he or she deserved voting eligibility). Unexpected error around edit count threshold revealed us if we made the threshold 200 instead of 400, plus 30,000 accounts would have got the right to vote. (Note: it shouldn't be equal to 30,000 people, it will include many secondary accounts here and there: Enwiki, Commons, meta or sister project where you are inactive ......) .
As part of Election committee, I personally think the requirements of this year was reasonable, but review is always welcome, specially based on census, poll or whatever.
On 7/18/07, Aphaia aphaia@gmail.com wrote:
<snippage>
As long as minimum subjective line of our community member's involvement sense matter, I think we don't need a new poll.
. . . <snip> . . .
As part of Election committee, I personally think the requirements of this year was reasonable, but review is always welcome, specially based on census, poll or whatever.
Hmm. I am confused. Are you against a poll or for it?
-- Jussi-Ville Heiskanen, ~ [[User:Cimon Avaro]]
Hoi, I have seen too many polls. I prefer arguments. Consider how many were involved in the elections, how well do you think a poll would do ? Thanks, GerardM
On 7/18/07, Jussi-Ville Heiskanen cimonavaro@gmail.com wrote:
On 7/18/07, Aphaia aphaia@gmail.com wrote:
<snippage>
As long as minimum subjective line of our community member's involvement sense matter, I think we don't need a new poll.
. . .
<snip> . . . > As part of Election committee, I personally think the requirements of > this year was reasonable, but review is always welcome, specially > based on census, poll or whatever.
Hmm. I am confused. Are you against a poll or for it?
-- Jussi-Ville Heiskanen, ~ [[User:Cimon Avaro]]
foundation-l mailing list foundation-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/foundation-l
On 7/18/07, GerardM gerard.meijssen@gmail.com wrote:
Hoi, I have seen too many polls. I prefer arguments. Consider how many were involved in the elections, how well do you think a poll would do ?
Okay. Do you have an argument to offer?
-- Jussi-Ville Heiskanen, ~ [[User:Cimon Avaro]]
On 7/18/07, Jussi-Ville Heiskanen cimonavaro@gmail.com wrote:
On 7/18/07, Aphaia aphaia@gmail.com wrote:
<snippage>
As long as minimum subjective line of our community member's involvement sense matter, I think we don't need a new poll.
. . .
<snip> . . . > As part of Election committee, I personally think the requirements of > this year was reasonable, but review is always welcome, specially > based on census, poll or whatever.
Hmm. I am confused. Are you against a poll or for it?
I am afraid you simplified my responses too much.
For the first quote, I pointed out we don't need to poll to learn what type of complaint exists. I don't even oppose "I feel myself qualified but Eleccom said differently. Yeeek" type pole. But from talk page interactions, I think we know already what kind of claims we have. For that purpose, we have not to have a poll. The claimed minimum line is "all editors including anons", and I don't think there is a much lower requirement.
For the second quote, rational review of rules and policies are always helpful in my opinion, specially when we know some grumbling about that. Such polls would however be different from the suggested at first, and I strongly suggest it should be intersubjective, what type of requirement the community or at least the majority of the community think adequate, ideally regardless how it affects themselves.
Hoi, I just provided an argument not to have polls.
Anyway, with Single User Login likely to be in production at the next board elections, 400 edits can be combined over the different projects. Realistically, it should be possible by the next year...
Thanks, GerardM
On 7/18/07, Jussi-Ville Heiskanen cimonavaro@gmail.com wrote:
On 7/18/07, GerardM gerard.meijssen@gmail.com wrote:
Hoi, I have seen too many polls. I prefer arguments. Consider how many were involved in the elections, how well do you think a poll would do ?
Okay. Do you have an argument to offer?
-- Jussi-Ville Heiskanen, ~ [[User:Cimon Avaro]]
foundation-l mailing list foundation-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/foundation-l
On 7/18/07, GerardM gerard.meijssen@gmail.com wrote:
Hoi, I just provided an argument not to have polls.
Anyway, with Single User Login likely to be in production at the next board elections, 400 edits can be combined over the different projects. Realistically, it should be possible by the next year...
Oops. Sorry. Didn't realize you meant you preferred arguments against having polls to polls.
-- Jussi-Ville Heiskanen, ~ [[User:Cimon Avaro]]
On 7/18/07, Aphaia aphaia@gmail.com wrote:
On 7/18/07, Jussi-Ville Heiskanen cimonavaro@gmail.com wrote:
On 7/18/07, Aphaia aphaia@gmail.com wrote:
<snippage>
As long as minimum subjective line of our community member's involvement sense matter, I think we don't need a new poll.
. . .
<snip> . . . > As part of Election committee, I personally think the requirements of > this year was reasonable, but review is always welcome, specially > based on census, poll or whatever.
Hmm. I am confused. Are you against a poll or for it?
I am afraid you simplified my responses too much.
For the first quote, I pointed out we don't need to poll to learn what type of complaint exists. I don't even oppose "I feel myself qualified but Eleccom said differently. Yeeek" type pole. But from talk page interactions, I think we know already what kind of claims we have. For that purpose, we have not to have a poll. The claimed minimum line is "all editors including anons", and I don't think there is a much lower requirement.
For the second quote, rational review of rules and policies are always helpful in my opinion, specially when we know some grumbling about that. Such polls would however be different from the suggested at first, and I strongly suggest it should be intersubjective, what type of requirement the community or at least the majority of the community think adequate, ideally regardless how it affects themselves.
On my part I think people are over-complicating things.
Either we need to tighten the voting requirements, so that we keep the franchise to those who care about the core of our values, or we need to keep things as close to current level as possible, or we need to see if we can involve a broader franchise.
Those are the three options (with some nuancing possible on each of them of course). Kim suggests one route, as I see it, Jimbo suggested the other, and if I read it correctly, you were kind of tending towards the middle ground.
What I have yet to see is a coherent argument for any of these three positions. From any corner.
Jimbo appeared to approach matters from a philosophic POV, without many specifics. Kim appeared to feel he needed to champion some broader mass of discontent, and you, again, if I read you correctly, were trying to sound a note pointing out that somebody actually has to administer the votes, and somebody will always complain, but solutions that satisfy everybody are hard to come by.
If my first response was too simple, I apologize. I hope this is not to verbose.
-- Jussi-Ville Heiskanen, ~ [[User:Cimon Avaro]]
On 7/18/07, GerardM gerard.meijssen@gmail.com wrote:
Hoi, I just provided an argument not to have polls.
Anyway, with Single User Login likely to be in production at the next board elections, 400 edits can be combined over the different projects. Realistically, it should be possible by the next year...
Realistically, how hard can it be to provide people with a method to link their accounts together? This should be possible by next week. Whether or not it's likely, on the other hand...
On Wed, July 18, 2007 11:38, Aphaia wrote:
Allow anons to vote. Period. Since 2005 the lowest claimed threshould I have ever seen claimed came from unregistered users.
and promptly encourage the most massive false reporting by effectively encouraging multiple voting? If anons were allowed to vote then the results would be completely meaningless and, imho, totally invalid.
Alison
Hello,
Eliminating username conflicts with unified login might make it possible for a third-party script to count edits on every wiki, but unified login will apparently not combine contribution logs. "Single user login" does not mean "single crosswiki account per user"; this common misconception might be the reason it is documented as "unified login".
For more information on what unified login will actually be, see < http://meta.wikimedia.org/wiki/Help:Unified_login >.
Yours cordially, Jesse Martin (Pathoschild)
On 7/18/07, GerardM gerard.meijssen@gmail.com wrote:
Anyway, with Single User Login likely to be in production at the next board elections, 400 edits can be combined over the different projects. Realistically, it should be possible by the next year...
On 7/18/07, Jesse Martin (Pathoschild) pathoschild@gmail.com wrote:
Hello,
Eliminating username conflicts with unified login might make it possible for a third-party script to count edits on every wiki, but unified login will apparently not combine contribution logs. "Single user login" does not mean "single crosswiki account per user"; this common misconception might be the reason it is documented as "unified login".
For more information on what unified login will actually be, see < http://meta.wikimedia.org/wiki/Help:Unified_login >.
"Since the new system only allows one user per name, there are some cases where accounts will need to be renamed."
What a horrible idea. I sure hope that's not what unified login will actually be.
"Since the new system only allows one user per name, there are some cases where accounts will need to be renamed."
What a horrible idea. I sure hope that's not what unified login will actually be.
There is no way you could have unified login without renaming accounts. If two people currently have the same name on different projects they cannot both continue to use that name after unified login, thus at least one of them must be renamed. (The one with the least edits is the plan, I think.)
Hoi, Well it is. It is the exact reason why it is so unpalatable that is has been so long in the making. With time passing by, this problem has become worse. Thanks, GerardM
On 7/18/07, Anthony wikimail@inbox.org wrote:
On 7/18/07, Jesse Martin (Pathoschild) pathoschild@gmail.com wrote:
Hello,
Eliminating username conflicts with unified login might make it possible for a third-party script to count edits on every wiki, but unified login will apparently not combine contribution logs. "Single user login" does not mean "single crosswiki account per user"; this common misconception might be the reason it is documented as "unified login".
For more information on what unified login will actually be, see < http://meta.wikimedia.org/wiki/Help:Unified_login >.
"Since the new system only allows one user per name, there are some cases where accounts will need to be renamed."
What a horrible idea. I sure hope that's not what unified login will actually be.
foundation-l mailing list foundation-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/foundation-l
Hello,
Yes, that is what unified login will actually be. The procedure for user name conflict resolution is pretty complex; see < http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/CentralAuth/evil-...
for more details.
Yours cordially, Jesse Martin (Pathoschild)
On 7/18/07, Anthony wikimail@inbox.org wrote:
"Since the new system only allows one user per name, there are some cases where accounts will need to be renamed."
What a horrible idea. I sure hope that's not what unified login will actually be.
On 7/18/07, Thomas Dalton thomas.dalton@gmail.com wrote:
"Since the new system only allows one user per name, there are some cases where accounts will need to be renamed."
What a horrible idea. I sure hope that's not what unified login will actually be.
There is no way you could have unified login without renaming accounts.
Based on the definition of "unified login", I guess not. Of course, I called the idea horrible, not the implementation.
On 7/18/07, GerardM gerard.meijssen@gmail.com wrote:
Hoi, Well it is. It is the exact reason why it is so unpalatable that is has been so long in the making. With time passing by, this problem has become worse. Thanks, GerardM
Well, there's always a chance that the whole concept is just going to be dropped, right? Does anyone actually care about unified login, as defined (having the same username on all wikis)? I know a lot of people care about the things which are supposedly dependent on unified login, like having unified contribution lists, and unified preferences, and unified talk page notification, but none of these things are actually dependent on unified login (if defined as having the same same username on all wikis).
Isn't it a GFDL violation to change someone's username (and thus their entries in the history section) without their permission?
On 7/18/07, Anthony wikimail@inbox.org wrote:
On 7/18/07, Jesse Martin (Pathoschild) pathoschild@gmail.com wrote:
Hello,
Eliminating username conflicts with unified login might make it possible for a third-party script to count edits on every wiki, but unified login will apparently not combine contribution logs. "Single user login" does not mean "single crosswiki account per user"; this common misconception might be the reason it is documented as "unified login".
For more information on what unified login will actually be, see < http://meta.wikimedia.org/wiki/Help:Unified_login >.
"Since the new system only allows one user per name, there are some cases where accounts will need to be renamed."
What a horrible idea. I sure hope that's not what unified login will actually be.
foundation-l mailing list foundation-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/foundation-l
Hoi, Do people care, absolutely. Does the GFDL have anything to say about the name of a user ID, absolutely not. It is about unambiguously attributing contributions.. I would even hazard to guess that the GFDL should welcome it. Thanks, GerardM
On 7/18/07, Anthony wikimail@inbox.org wrote:
On 7/18/07, GerardM gerard.meijssen@gmail.com wrote:
Hoi, Well it is. It is the exact reason why it is so unpalatable that is has
been
so long in the making. With time passing by, this problem has become
worse.
Thanks, GerardM
Well, there's always a chance that the whole concept is just going to be dropped, right? Does anyone actually care about unified login, as defined (having the same username on all wikis)? I know a lot of people care about the things which are supposedly dependent on unified login, like having unified contribution lists, and unified preferences, and unified talk page notification, but none of these things are actually dependent on unified login (if defined as having the same same username on all wikis).
Isn't it a GFDL violation to change someone's username (and thus their entries in the history section) without their permission?
On 7/18/07, Anthony wikimail@inbox.org wrote:
On 7/18/07, Jesse Martin (Pathoschild) pathoschild@gmail.com wrote:
Hello,
Eliminating username conflicts with unified login might make it possible for a third-party script to count edits on every wiki, but unified login will apparently not combine contribution logs. "Single user login" does not mean "single crosswiki account per user"; this common misconception might be the reason it is documented as
"unified
login".
For more information on what unified login will actually be, see < http://meta.wikimedia.org/wiki/Help:Unified_login >.
"Since the new system only allows one user per name, there are some cases where accounts will need to be renamed."
What a horrible idea. I sure hope that's not what unified login will actually be.
foundation-l mailing list foundation-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/foundation-l
Kim Bruning wrote:
On Sat, Jul 14, 2007 at 11:24:05AM -0700, Jimmy Wales wrote:
I think we mostly do not want the board of the foundation elected by casual users or the general public, but by "the core group of the community" .
This could be a bit of a problem, since I have a feeling that several dedicated community members were excluded this time around. In the case of some well known community members (like for instance Jan-Bart iirc), this got corrected. But as always in such cases, it might be wise to investigate a little further, you know, just in case you're looking at the tip of an iceberg you didn't know was there.
Perhaps a poll along the lines of "I feel like I'm a member of the community, but nevertheless was not allowed to vote" would be useful?
I still believe that single log-in would go a long way to simplify some of these problems. It would allow for aggregating qualifying edits across projects.
Someone who is not allowed to vote needs to raise the problem before it's too late to do anything about it. If there are problems this is one place where anecdotal evidence is helpful. I don't see what good a poll will do.
Ec
Isn't it a GFDL violation to change someone's username (and thus their entries in the history section) without their permission?
No. It would probably be wise to put a note on the user page saying that this user was formally known as X, but that should be all that is required.
The current rename function doesn't move everything (eg. deleted edits), so this would need to be fixed, but I imagine that is a tiny job in comparison to the rest.
As a steward, I would love to have unified login. There are 638 wikis where I still need to manually register an account so that I can respond on any wiki without delay < http://meta.wikimedia.org/wiki/User:Pathoschild/Sandbox2 >.
But... aren't we getting sonewhat off-topic?
Yours cordially, Jesse Martin (Pathoschild)
On 7/18/07, Anthony wikimail@inbox.org wrote:
Does anyone actually care about unified login, as defined (having the same username on all wikis)? I know a lot of people care about the things which are supposedly dependent on unified login, like having unified contribution lists, and unified preferences, and unified talk page notification, but none of these things are actually dependent on unified login (if defined as having the same same username on all wikis).
On 7/18/07, Jesse Martin (Pathoschild) pathoschild@gmail.com wrote:
As a steward, I would love to have unified login. There are 638 wikis where I still need to manually register an account so that I can respond on any wiki without delay < http://meta.wikimedia.org/wiki/User:Pathoschild/Sandbox2 >.
Unified login wouldn't help, because user rights are local. You'd just have 638 accounts with no user rights.
And it's also possible to automate such account creation without implementing unified login (without renaming any accounts).
But... aren't we getting sonewhat off-topic?
Off the topic of the thread, but not off the topic of the mailing list.
Yours cordially, Jesse Martin (Pathoschild)
On 7/18/07, Anthony wikimail@inbox.org wrote:
Does anyone actually care about unified login, as defined (having the same username on all wikis)? I know a lot of people care about the things which are supposedly dependent on unified login, like having unified contribution lists, and unified preferences, and unified talk page notification, but none of these things are actually dependent on unified login (if defined as having the same same username on all wikis).
foundation-l mailing list foundation-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/foundation-l
I would also say that there were a VERY few cases raised to the Election Committee about someone who felt like they should have been able to vote and weren't. Those few that were (ie, Jan-Bart, some developers with shell access that don't actually edit on-wiki, etc) got a hearing and I think most everyone was pleased with the outcome.
All ya gotta do is ask, folks... we'd have listened, I promise.
Philippe ----- Original Message ----- From: Ray Saintonge To: Wikimedia Foundation Mailing List Sent: Wednesday, July 18, 2007 1:06 PM Subject: Re: [Foundation-l] Design goals for the election and board selection process
Kim Bruning wrote:
On Sat, Jul 14, 2007 at 11:24:05AM -0700, Jimmy Wales wrote:
I think we mostly do not want the board of the foundation elected by casual users or the general public, but by "the core group of the community" .
This could be a bit of a problem, since I have a feeling that several dedicated community members were excluded this time around. In the case of some well known community members (like for instance Jan-Bart iirc), this got corrected. But as always in such cases, it might be wise to investigate a little further, you know, just in case you're looking at the tip of an iceberg you didn't know was there.
Perhaps a poll along the lines of "I feel like I'm a member of the community, but nevertheless was not allowed to vote" would be useful?
I still believe that single log-in would go a long way to simplify some of these problems. It would allow for aggregating qualifying edits across projects.
Someone who is not allowed to vote needs to raise the problem before it's too late to do anything about it. If there are problems this is one place where anecdotal evidence is helpful. I don't see what good a poll will do.
Ec
_______________________________________________ foundation-l mailing list foundation-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/foundation-l
Unified login would register the 638 remaining accounts. I don't need user rights on those wikis; stewards add rights from Meta when they're needed, and remove them when they're done.
I'm not aware of any current way to automate account creation, since captchas must be solved when registering on all Wikimedia wikis.
Yours cordially, Jesse Martin (Pathoschild)
On 7/18/07, Anthony wikimail@inbox.org wrote:
On 7/18/07, Jesse Martin (Pathoschild) pathoschild@gmail.com wrote:
As a steward, I would love to have unified login. There are 638 wikis where I still need to manually register an account so that I can respond on any wiki without delay < http://meta.wikimedia.org/wiki/User:Pathoschild/Sandbox2 >.
Unified login wouldn't help, because user rights are local. You'd just have 638 accounts with no user rights.
And it's also possible to automate such account creation without implementing unified login (without renaming any accounts).
Yes, of course you would, but right now a steward has to: *Notice that the request exists *Check whether he has an account. If so: log in *If not: create account. *Confirm emailaddress *The finally he can give himself the needed rights.
By then over 50 vandal renames can be done by WoW & Co. Unified login would take at least away the "check whether he has account" and "create account" because he will have an account per definition of single user. The email doesnt have to be confirmed anymore. He only needs to give a short link on his userpage and grant himself (herself) the rights.
BR, Lodewijk
2007/7/18, Anthony wikimail@inbox.org:
On 7/18/07, Jesse Martin (Pathoschild) pathoschild@gmail.com wrote:
As a steward, I would love to have unified login. There are 638 wikis where I still need to manually register an account so that I can respond on any wiki without delay < http://meta.wikimedia.org/wiki/User:Pathoschild/Sandbox2 >.
Unified login wouldn't help, because user rights are local. You'd just have 638 accounts with no user rights.
And it's also possible to automate such account creation without implementing unified login (without renaming any accounts).
But... aren't we getting sonewhat off-topic?
Off the topic of the thread, but not off the topic of the mailing list.
Yours cordially, Jesse Martin (Pathoschild)
On 7/18/07, Anthony wikimail@inbox.org wrote:
Does anyone actually care about unified login, as defined (having the same username on all wikis)? I know a lot of people care about the things which are supposedly dependent on unified login, like having unified contribution lists, and unified preferences, and unified talk page notification, but none of these things are actually dependent on unified login (if defined as having the same same username on all wikis).
foundation-l mailing list foundation-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/foundation-l
On 7/18/07, Jesse Martin (Pathoschild) pathoschild@gmail.com wrote:
Unified login would register the 638 remaining accounts. I don't need user rights on those wikis; stewards add rights from Meta when they're needed, and remove them when they're done.
I'm not aware of any current way to automate account creation, since captchas must be solved when registering on all Wikimedia wikis.
It would have to be done by a developer, of course. Just implement unified login minus the account renaming bit.
On 7/18/07, Anthony wikimail@inbox.org wrote:
On 7/18/07, Jesse Martin (Pathoschild) pathoschild@gmail.com wrote:
As a steward, I would love to have unified login. There are 638 wikis where I still need to manually register an account so that I can respond on any wiki without delay < http://meta.wikimedia.org/wiki/User:Pathoschild/Sandbox2 >.
Unified login wouldn't help, because user rights are local. You'd just have 638 accounts with no user rights.
And it's also possible to automate such account creation without implementing unified login (without renaming any accounts).
foundation-l mailing list foundation-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/foundation-l
On 7/18/07, effe iets anders effeietsanders@gmail.com wrote:
Yes, of course you would, but right now a steward has to: *Notice that the request exists *Check whether he has an account. If so: log in *If not: create account. *Confirm emailaddress *The finally he can give himself the needed rights.
By then over 50 vandal renames can be done by WoW & Co. Unified login would take at least away the "check whether he has account" and "create account" because he will have an account per definition of single user. The email doesnt have to be confirmed anymore. He only needs to give a short link on his userpage and grant himself (herself) the rights.
Why does the email have to be confirmed in the first place? Can't the account be created without an email address? I can't imagine the time savings is as significant as you're making it out to be, and there are lots of ways to solve this problem which don't involve having the same username on all wikis.
In fact, the username is irrelevant. A faster way to resolve the problem would be:
*Notice that the request exists *Create an account with a random username and no email address *The finally he can give himself the needed rights.
Anthony
Hoi, We have passed the point of discussing functionality for SUL. Much of the software has been programmed. It needs finishing and it needs implementation.
With compulsory e-mail confirmation we make vandalism slightly more difficult. It has the added benefit that a user can request help with his password when it is forgotten. Time saving is not really an issue for normal users, it does not cost much time. For the users we would prefer to pass us by, creating a working e-mail account does take time ... great :)
Thanks, GerardM
On 7/18/07, Anthony wikimail@inbox.org wrote:
On 7/18/07, effe iets anders effeietsanders@gmail.com wrote:
Yes, of course you would, but right now a steward has to: *Notice that the request exists *Check whether he has an account. If so: log in *If not: create account. *Confirm emailaddress *The finally he can give himself the needed rights.
By then over 50 vandal renames can be done by WoW & Co. Unified login
would
take at least away the "check whether he has account" and "create
account"
because he will have an account per definition of single user. The email doesnt have to be confirmed anymore. He only needs to give a short link
on
his userpage and grant himself (herself) the rights.
Why does the email have to be confirmed in the first place? Can't the account be created without an email address? I can't imagine the time savings is as significant as you're making it out to be, and there are lots of ways to solve this problem which don't involve having the same username on all wikis.
In fact, the username is irrelevant. A faster way to resolve the problem would be:
*Notice that the request exists *Create an account with a random username and no email address *The finally he can give himself the needed rights.
Anthony
foundation-l mailing list foundation-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/foundation-l
Anthony wrote:
On 7/18/07, GerardM gerard.meijssen@gmail.com wrote:
Hoi, I just provided an argument not to have polls.
Anyway, with Single User Login likely to be in production at the next board elections, 400 edits can be combined over the different projects. Realistically, it should be possible by the next year...
Realistically, how hard can it be to provide people with a method to link their accounts together? This should be possible by next week. Whether or not it's likely, on the other hand...
It's been going to be done next week for the last four years. :-)
Ec
yeah, sure... I wonder when an account that cannot be identified, has no email or description would suddenly delete pages, how would people react... No, random account doesnt sound like you've read yourself in very much into stewardswork...
Lodewijk
2007/7/18, Anthony wikimail@inbox.org:
On 7/18/07, effe iets anders effeietsanders@gmail.com wrote:
Yes, of course you would, but right now a steward has to: *Notice that the request exists *Check whether he has an account. If so: log in *If not: create account. *Confirm emailaddress *The finally he can give himself the needed rights.
By then over 50 vandal renames can be done by WoW & Co. Unified login
would
take at least away the "check whether he has account" and "create
account"
because he will have an account per definition of single user. The email doesnt have to be confirmed anymore. He only needs to give a short link
on
his userpage and grant himself (herself) the rights.
Why does the email have to be confirmed in the first place? Can't the account be created without an email address? I can't imagine the time savings is as significant as you're making it out to be, and there are lots of ways to solve this problem which don't involve having the same username on all wikis.
In fact, the username is irrelevant. A faster way to resolve the problem would be:
*Notice that the request exists *Create an account with a random username and no email address *The finally he can give himself the needed rights.
Anthony
On 7/18/07, GerardM gerard.meijssen@gmail.com wrote:
Hoi, We have passed the point of discussing functionality for SUL. Much of the software has been programmed. It needs finishing and it needs implementation.
From the comments by Jesse it seems not very many people even know
what the functionality for SUL is. What it needs is to be scrapped and reconsidered.
With compulsory e-mail confirmation we make vandalism slightly more difficult. It has the added benefit that a user can request help with his password when it is forgotten. Time saving is not really an issue for normal users, it does not cost much time. For the users we would prefer to pass us by, creating a working e-mail account does take time ... great :)
Umm, that has absolutely nothing to do with what I was saying. E-mail confirmation is not currently required, so that is not a step that should be included in a steward's required steps to fight page move vandalism.
On 7/18/07, Anthony wikimail@inbox.org wrote:
On 7/18/07, effe iets anders effeietsanders@gmail.com wrote:
Yes, of course you would, but right now a steward has to: *Notice that the request exists *Check whether he has an account. If so: log in *If not: create account. *Confirm emailaddress *The finally he can give himself the needed rights.
By then over 50 vandal renames can be done by WoW & Co. Unified login
would
take at least away the "check whether he has account" and "create
account"
because he will have an account per definition of single user. The email doesnt have to be confirmed anymore. He only needs to give a short link
on
his userpage and grant himself (herself) the rights.
Why does the email have to be confirmed in the first place? Can't the account be created without an email address? I can't imagine the time savings is as significant as you're making it out to be, and there are lots of ways to solve this problem which don't involve having the same username on all wikis.
In fact, the username is irrelevant. A faster way to resolve the problem would be:
*Notice that the request exists *Create an account with a random username and no email address *The finally he can give himself the needed rights.
Anthony
foundation-l mailing list foundation-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/foundation-l
On 7/18/07, effe iets anders effeietsanders@gmail.com wrote:
yeah, sure... I wonder when an account that cannot be identified, has no email or description would suddenly delete pages, how would people react...
Apparently you think you have a good idea of how people would react to a random account name being created and fixing page move vandalism on a wiki which is extremely inactive, though? I think it'd be a combination of relief and questions of WTF, which of course would be answered after as soon as the problem was taken care of.
No, random account doesnt sound like you've read yourself in very much into stewardswork...
I was commenting on a particular scenario which I was given, by you, and stated that creating an account with a random name would be a faster way to resolve the problem than the solution which you presented.
Lodewijk
2007/7/18, Anthony wikimail@inbox.org:
On 7/18/07, effe iets anders effeietsanders@gmail.com wrote:
Yes, of course you would, but right now a steward has to: *Notice that the request exists *Check whether he has an account. If so: log in *If not: create account. *Confirm emailaddress *The finally he can give himself the needed rights.
By then over 50 vandal renames can be done by WoW & Co. Unified login
would
take at least away the "check whether he has account" and "create
account"
because he will have an account per definition of single user. The email doesnt have to be confirmed anymore. He only needs to give a short link
on
his userpage and grant himself (herself) the rights.
Why does the email have to be confirmed in the first place? Can't the account be created without an email address? I can't imagine the time savings is as significant as you're making it out to be, and there are lots of ways to solve this problem which don't involve having the same username on all wikis.
In fact, the username is irrelevant. A faster way to resolve the problem would be:
*Notice that the request exists *Create an account with a random username and no email address *The finally he can give himself the needed rights.
Anthony
Confirming the email address allows users to more easily contact us, which is necessary given our public function. It also ties our hundreds of user accounts together for automated merging, in case unified login ever gets implemented. Remember that these are permanent accounts that are sometimes used to perform high-profile administrator, bureaucrat, checkuser, or oversight duties.
Registering random user names is not practical. When processing a request, we must first assign the necessary user rights on that wiki. For example, I would assign rights to "Pathoschild@fawiki" if a steward admin/bureaucrat/checkuser/oversighter was needed on the Persian Wikipedia. This is easy if the usernames are the same, since we just assign the rights to our username appended with the database prefix. If the user name is random, however, we must first either look up which random string we used on that wiki, or register a new random user name.
Although getting a developer with shell access to register accounts globally would work, I don't think many would be willing. Even if this service was strictly limited to stewards, that would include 30 users.
Yours cordially, Jesse Martin (Pathoschild)
On 7/18/07, Anthony wikimail@inbox.org wrote:
Why does the email have to be confirmed in the first place? Can't the account be created without an email address? I can't imagine the time savings is as significant as you're making it out to be, and there are lots of ways to solve this problem which don't involve having the same username on all wikis.
In fact, the username is irrelevant. A faster way to resolve the problem would be:
*Notice that the request exists *Create an account with a random username and no email address *The finally he can give himself the needed rights.
On 7/18/07, Jesse Martin (Pathoschild) pathoschild@gmail.com wrote:
Confirming the email address allows users to more easily contact us, which is necessary given our public function. It also ties our hundreds of user accounts together for automated merging, in case unified login ever gets implemented. Remember that these are permanent accounts that are sometimes used to perform high-profile administrator, bureaucrat, checkuser, or oversight duties.
The email address could always be confirmed later in emergency situations, though.
Registering random user names is not practical. When processing a request, we must first assign the necessary user rights on that wiki. For example, I would assign rights to "Pathoschild@fawiki" if a steward admin/bureaucrat/checkuser/oversighter was needed on the Persian Wikipedia. This is easy if the usernames are the same, since we just assign the rights to our username appended with the database prefix. If the user name is random, however, we must first either look up which random string we used on that wiki, or register a new random user name.
I'm sorry I mentioned it. I should have just left it at the fact that the few seconds it takes to create the account isn't that big of a deal.
Although getting a developer with shell access to register accounts globally would work, I don't think many would be willing. Even if this service was strictly limited to stewards, that would include 30 users.
It's certainly an easier script to write than full blown single username unification, or whatever the heck it's called (I'm not looking it up). It wouldn't even have to be strictly limited to stewards. The only part I'm taking issue with is "there are some cases where accounts will need to be renamed".
I'm certainly not going to agree to rename my en username. If it happens it'll happen forcibly. Now in my particular case I doubt there are any other Anthony DiPierro's on other wikis with over 16,799 edits, but I guarantee you some other active users are going to have names that collide.
On 7/18/07, Anthony wikimail@inbox.org wrote:
On 7/18/07, Jesse Martin (Pathoschild) pathoschild@gmail.com wrote:
Although getting a developer with shell access to register accounts globally would work, I don't think many would be willing. Even if this service was strictly limited to stewards, that would include 30 users.
It's certainly an easier script to write than full blown single username unification, or whatever the heck it's called (I'm not looking it up). It wouldn't even have to be strictly limited to stewards. The only part I'm taking issue with is "there are some cases where accounts will need to be renamed".
Clarifying, I wouldn't have any problem with a script which went through and, for each username, chose a "winner" through some reasonable algorithm (e.g. highest number of recent edits) and then created an account with the same username, email, and password on every wiki where that username didn't already exist. That seems to be roughly equal to stage 1 of the current single username unification (TM) scheme.
Anthony wrote:
On 7/18/07, Jesse Martin (Pathoschild) pathoschild@gmail.com wrote:
Hello,
Eliminating username conflicts with unified login might make it possible for a third-party script to count edits on every wiki, but unified login will apparently not combine contribution logs. "Single user login" does not mean "single crosswiki account per user"; this common misconception might be the reason it is documented as "unified login".
For more information on what unified login will actually be, see < http://meta.wikimedia.org/wiki/Help:Unified_login >.
"Since the new system only allows one user per name, there are some cases where accounts will need to be renamed."
What a horrible idea. I sure hope that's not what unified login will actually be.
Why is that such a hoorrible idea?
I suspect that the naming conflicts are bigger now than when the whole idea was first bruited.
Ec
Anthony wrote:
Well, there's always a chance that the whole concept is just going to be dropped, right? Does anyone actually care about unified login, as defined (having the same username on all wikis)? I know a lot of people care about the things which are supposedly dependent on unified login, like having unified contribution lists, and unified preferences, and unified talk page notification, but none of these things are actually dependent on unified login (if defined as having the same same username on all wikis).
Maybe the people who participate on several wikis, and who don't want to remember a different name for each one. Or those with a good established reputation who could find someone using their name on a different wiki with less than flattering results.
Isn't it a GFDL violation to change someone's username (and thus their entries in the history section) without their permission?
I'm sure that if that is the case we could provide a reasonable temporary name to the one who must change.
Ec
Anthony wrote:
On 7/18/07, Jesse Martin (Pathoschild) pathoschild@gmail.com wrote:
Unified login would register the 638 remaining accounts. I don't need user rights on those wikis; stewards add rights from Meta when they're needed, and remove them when they're done.
I'm not aware of any current way to automate account creation, since captchas must be solved when registering on all Wikimedia wikis.
It would have to be done by a developer, of course. Just implement unified login minus the account renaming bit.
Simply preventing newbies from creating an account with a name that already exists on any account would be a good first step
Ec
wikimedia-l@lists.wikimedia.org