The more I think about it, the more I wonder if we did not make entirely a mistake (me definitly included)
History of checkuser (please take a seat and have a tea, it will be long)
1) originally, Brion took care of ip checking upon requests. He did the checks apparently only when he knew the one asking (=trusted). It was done directly in the database (so, required developer status and meant no log of checks)
2) when requests became more numerous, Tim Starling and perhaps others started to help
3) came a moment when not only requests were too numerous (and developers probably tired of doing this), but on top, some editors had the developer status only to make ip checks (I understood it was the case of Taw at least). There was apparently a will to clean up who had access, and to limit it to those who were *really* developing
At this point, it was largely admitted that the job was the one of a developer. A *technical* job. Though I know at least one person had access to the db last summer or fall to do this and is not to my knowledge a developer (Elian, can you confirm this ?)
4) Tim developped the tool. Apparently, the first to have access to it were Taw and David. Both developers. All was fine.
5) This is the moment where it slipped. First David started saying that more people would be needed for the english wikipedia checks. Requests generally came from the arbcom quite naturally. Without the tool, the arbcom would have asked Brion or Tim to do the checks. With the tool, it was quite a natural direction.... to request access for the arbcom members. And here was the first mistake !
On top, other languages (who were previously asking Brion or Tim, and had no more developers available to do this at that moment) started asking for access. And what was insisted upon was the "confidentiality" side, much more than the "technicality" side. Second mistake.
But quite clearly.... the technical consideration is just as important than the confidentiality consideration.
I plead guilty for part of this. I also think the arbcom of last summer has a responsability in this, since it was asking for the arbcom to have access, regardless of technical ability of its members. And for what is worth, I think Jimbo also has a responsability in this, since he himself decided all english arbcom members would have access.
Then, there was a third mistake I think (it is not an accusation, just an analysis). It was to make a tool dividing projects and languages. Originally, we had a common set of volunteers to help us all. And this was good. I am pretty sure some people did not know Brion intimately enough to *trust* him, but they were told he was fine by people they trusted, and they went to ask him with no fear. And Jimbo had no fear either.
Now, people have checkuser status only on one project/one language. Just as if Brion had help ip checking on the french wiktionary, whilst Tim was dedicated to the english wikipedia and Taw to the polish wikibooks. It makes NO sense whatsoever. The *only* unigue advantage of the current system is to understand the language of the project the checkuser make the job.
And as a result of this mix-up... because of the need to "trust" the checkuser, we have zizanie (does that exist in english ?). We have internal fight and rancor).
The small languages are complaining they are left aside
The non-wikipedia projects are complaining they are left aside
The stewards are complaining they do not have the technical ability to do this
And the checkusers with the technical ability... pretty much offer to help anyone who needs help.
What that suggest me is this
We should not have checkusers with the tool access on a one project/one language, but a POOL of COMMON checkusers. Those should all have good technical abilities. Those would have access everywhere. They would be listed on meta with their language ability. The biggest projects would be used to always ask to their favorites. The small languages will try to find the one with a basic knowledge of their language if they wish.
But all in all, checkusers should be a common good, just as our developers right now are (and, hell, just as your board members are).
Ant
On 4/22/06, Anthere Anthere9@yahoo.com wrote:
We should not have checkusers with the tool access on a one project/one language, but a POOL of COMMON checkusers. Those should all have good technical abilities. Those would have access everywhere. They would be listed on meta with their language ability. The biggest projects would be used to always ask to their favorites. The small languages will try to find the one with a basic knowledge of their language if they wish.
But all in all, checkusers should be a common good, just as our developers right now are (and, hell, just as your board members are).
Ant
I agree with this proposal.
The smaller wikis cannot benefit from checks because there are far too few users with global CheckUser access; on the other hand, they cannot have local checks because their candidates are unknown to and not trusted by the wider community. Local CheckUser access furthermore causes previously discussed confidentiality problems, since the number of users required would be disproportionately high in order to serve every project in need.
Having a relatively small number of users with global CheckUser access, perhaps combined with the proposed 'Guest' CheckUser process, will much better serve a middle ground between access and confidentiality. These users would probably be most active on projects they participate most in, serving as the de facto local CheckUser agents. Projects without such local agents would likely still be forced to wait, but the larger number of CheckUser agents may help alleviate waiting times on the Meta request page.
-- Jesse Martin ([[User:Pathoschild]])
On 4/22/06, Anthere Anthere9@yahoo.com wrote:
We should not have checkusers with the tool access on a one project/one language, but a POOL of COMMON checkusers. Those should all have good technical abilities. Those would have access everywhere. They would be listed on meta with their language ability. The biggest projects would be used to always ask to their favorites. The small languages will try to find the one with a basic knowledge of their language if they wish.
But all in all, checkusers should be a common good, just as our developers right now are (and, hell, just as your board members are).
Ant
I agree with this; making checkuser a global permission would be absolutely fine with me.
Jesse Martin wrote:
I agree with this proposal.
The smaller wikis cannot benefit from checks because there are far too few users with global CheckUser access; on the other hand, they cannot have local checks because their candidates are unknown to and not trusted by the wider community. Local CheckUser access furthermore causes previously discussed confidentiality problems, since the number of users required would be disproportionately high in order to serve every project in need.
Having a relatively small number of users with global CheckUser access, perhaps combined with the proposed 'Guest' CheckUser process, will much better serve a middle ground between access and confidentiality. These users would probably be most active on projects they participate most in, serving as the de facto local CheckUser agents. Projects without such local agents would likely still be forced to wait, but the larger number of CheckUser agents may help alleviate waiting times on the Meta request page.
I can't speak for other checkers, I can only speak for myself, but I guarantee that I will not make any project wait an undue amount of time (I don't consider 24 hours or so to be undue, unless it is an absolute emergency [e.g., a mass vandal attack that needs checkuser to pull the IP and rangeblock]; even checkusers have to venture into the offline world once in a while :-D ).
However, I can say that the amount of time you wait will be dramatically reduced by pointing out your request somewhere I look frequently, i.e., my en.wiki talk page, email, or on IRC. I check my meta watchlist once, maybe twice a day, because there just isn't enough activity on Meta to require checking it every fifteen minutes. I check my en.wiki talk page whenever the little bar pops up on my page; I never ignore it (as it drives me crazy until I do check it. I get an alert whenever I get a new email, and a new private message forces itself to the front of my screen. My point: Mediums that notify me of new activity immediately get checked more frequently.
As I understand it, requests are made and will continue to be made on a page on Meta; rather than expecting stewards or checkusers to put the page on autorefresh and check it every ten seconds, it would be helpful for users who want a check done right away to call our attention to it. I think others can testify that whenever they point a request out to me directly, rather than just waiting for the next time someone checks the page, I get it taken care of right away; I think this is a pretty standard practice, really: pointing a developer to the bugzilla report you filed gets it noticed more quickly, pointing a steward to your permissions request gets it done right away, etc.
Essjay
http://en.wikipedia.org/wiki/User:Essjay Wikipedia:The Free Encyclopedia http://www.wikipedia.org/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Anthere wrote:
[Snip "CheckUser is a bit of a mess"]
I plead guilty for part of this.
I don't think that it's fair to blame anyone in particular for a possibly non-optimal situation; certainly, what with your sterling work getting an agreeable, if not perfect, policy in place, we would have been in a much worse position without you. :-)
I also think the arbcom of last summer has a responsability in this, since it was asking for the arbcom to have access, regardless of technical ability of its members.
I disagree with this; we said that we had one or two members who were (far) more than sufficiently expert to be able to carry out the analysis, and that it would be more sensible to have them carry it out directly, rather than via the developers in the scant few moments they weren't busy doing their fantastic work running the sites.
And for what is worth, I think Jimbo also has a responsability in this, since he himself decided all english arbcom members would have access.
Except, err, we don't all have access; we chose who on our project has both a sufficient (very great) level of trust, and also sufficient technical expertise (or the willingness and aptitude to improve their skills in this area a little). For example, I have elected not to have access to the tool (though more for reasons of time).
Then, there was a third mistake I think (it is not an accusation, just an analysis). It was to make a tool dividing projects and languages. Originally, we had a common set of volunteers to help us all. And this was good. I am pretty sure some people did not know Brion intimately enough to *trust* him, but they were told he was fine by people they trusted, and they went to ask him with no fear. And Jimbo had no fear either.
Now, people have checkuser status only on one project/one language. Just as if Brion had help ip checking on the french wiktionary, whilst Tim was dedicated to the english wikipedia and Taw to the polish wikibooks. It makes NO sense whatsoever. The *only* unigue advantage of the current system is to understand the language of the project the checkuser make the job.
I agree, this is indeed a problem.
[Snip]
What that suggest me is this
We should not have checkusers with the tool access on a one project/one language, but a POOL of COMMON checkusers. Those should all have good technical abilities. Those would have access everywhere. They would be listed on meta with their language ability. The biggest projects would be used to always ask to their favorites. The small languages will try to find the one with a basic knowledge of their language if they wish.
But all in all, checkusers should be a common good, just as our developers right now are (and, hell, just as your board members are).
I think that this solution has some merit, but there exists the tricky problem of language - if one does not read Russian, then no matter how accurate and wide one's technical knowledge is, there is no point being asked to carry out CheckUser checks on people. It isn't merely about technical proficiency, but about judgement of editing patterns, of style, and of content. This is something that is definitely language-specific.
Yours sincerely, - -- James D. Forrester Wikimedia : [[W:en:User:Jdforrester|James F.]] E-Mail : james@jdforrester.org IM (MSN) : jamesdforrester@hotmail.com
The biggest problem with the English arbitrators is that due to the press of arbitration business they have little time to do justice to checkuser requests from other users. Access is vital to carrying out arbitration duties in some cases, however. One side effect is that some arbitrators have been drawn away from arbitration duties, perhaps for the good of the project as a whole, but drawn away nevertheless.
I think the technical expertise problem is exaggerated, so long as the investigator relies on investigations of editing patterns also.
Fred
On Apr 22, 2006, at 7:03 AM, James D. Forrester wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Anthere wrote:
[Snip "CheckUser is a bit of a mess"]
I plead guilty for part of this.
I don't think that it's fair to blame anyone in particular for a possibly non-optimal situation; certainly, what with your sterling work getting an agreeable, if not perfect, policy in place, we would have been in a much worse position without you. :-)
I also think the arbcom of last summer has a responsability in this, since it was asking for the arbcom to have access, regardless of technical ability of its members.
I disagree with this; we said that we had one or two members who were (far) more than sufficiently expert to be able to carry out the analysis, and that it would be more sensible to have them carry it out directly, rather than via the developers in the scant few moments they weren't busy doing their fantastic work running the sites.
And for what is worth, I think Jimbo also has a responsability in this, since he himself decided all english arbcom members would have access.
Except, err, we don't all have access; we chose who on our project has both a sufficient (very great) level of trust, and also sufficient technical expertise (or the willingness and aptitude to improve their skills in this area a little). For example, I have elected not to have access to the tool (though more for reasons of time).
Then, there was a third mistake I think (it is not an accusation, just an analysis). It was to make a tool dividing projects and languages. Originally, we had a common set of volunteers to help us all. And this was good. I am pretty sure some people did not know Brion intimately enough to *trust* him, but they were told he was fine by people they trusted, and they went to ask him with no fear. And Jimbo had no fear either.
Now, people have checkuser status only on one project/one language. Just as if Brion had help ip checking on the french wiktionary, whilst Tim was dedicated to the english wikipedia and Taw to the polish wikibooks. It makes NO sense whatsoever. The *only* unigue advantage of the current system is to understand the language of the project the checkuser make the job.
I agree, this is indeed a problem.
[Snip]
What that suggest me is this
We should not have checkusers with the tool access on a one project/one language, but a POOL of COMMON checkusers. Those should all have good technical abilities. Those would have access everywhere. They would be listed on meta with their language ability. The biggest projects would be used to always ask to their favorites. The small languages will try to find the one with a basic knowledge of their language if they wish.
But all in all, checkusers should be a common good, just as our developers right now are (and, hell, just as your board members are).
I think that this solution has some merit, but there exists the tricky problem of language - if one does not read Russian, then no matter how accurate and wide one's technical knowledge is, there is no point being asked to carry out CheckUser checks on people. It isn't merely about technical proficiency, but about judgement of editing patterns, of style, and of content. This is something that is definitely language-specific.
Yours sincerely,
James D. Forrester Wikimedia : [[W:en:User:Jdforrester|James F.]] E-Mail : james@jdforrester.org IM (MSN) : jamesdforrester@hotmail.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFESimhd7WnstdBQBkRAluVAJ9e+HWFpVDjs36+e1SkQqBaSUNP1ACbBkid 3R+fXP3EjNJR5QLP8wpGJ7s= =FCbz -----END PGP SIGNATURE----- _______________________________________________ foundation-l mailing list foundation-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/foundation-l
On 4/22/06, Fred Bauder fredbaud@ctelco.net wrote:
The biggest problem with the English arbitrators is that due to the press of arbitration business they have little time to do justice to checkuser requests from other users. Access is vital to carrying out arbitration duties in some cases, however. One side effect is that some arbitrators have been drawn away from arbitration duties, perhaps for the good of the project as a whole, but drawn away nevertheless.
This is probably the reason why Essjay and myself do the bulk of the checkuser activities on enwiki.
Kelly
James D. Forrester wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Anthere wrote:
[Snip "CheckUser is a bit of a mess"]
I plead guilty for part of this.
I don't think that it's fair to blame anyone in particular for a possibly non-optimal situation;
No. The issue is absolutely not to *blame* anyone. We all tried to find a solution at that time, and we may just not have found the best solution. I wanted to insist that I was part of that bad choice because I think it is more honest and because I do not want anyone jumping on this and saying "but it is your fault, so why do you bug us today ?". We did what we thought best. It is worth analysing (imho) where and why we chose directions which were not the best so that we can now modify this.
What that suggest me is this
We should not have checkusers with the tool access on a one project/one language, but a POOL of COMMON checkusers. Those should all have good technical abilities. Those would have access everywhere. They would be listed on meta with their language ability. The biggest projects would be used to always ask to their favorites. The small languages will try to find the one with a basic knowledge of their language if they wish.
But all in all, checkusers should be a common good, just as our developers right now are (and, hell, just as your board members are).
I think that this solution has some merit, but there exists the tricky problem of language - if one does not read Russian, then no matter how accurate and wide one's technical knowledge is, there is no point being asked to carry out CheckUser checks on people. It isn't merely about technical proficiency, but about judgement of editing patterns, of style, and of content. This is something that is definitely language-specific.
Yours sincerely,
James D. Forrester
Yup. But this is no different of what developers were doing for us before. For example, when Tim Starling made a check for us, he was not alone. It was rather an exchange where userA explained the issue, Tim gave a couple of answers, depending on the answers userA explored and possibly ask more information from Tim.
It is interesting though, that you give the example of a russian problem. We currently have standing in the board queue on OTRS, a request from a russian editor, asking that we investigate the case of a sysop abuse over there. The request travelled back and fro between the info en queue and the board queue. And since no one on either queue reads russian... well nothing happens. The *good* solution would be to know a trusted russian editor, who could be asked to give information.
Similarly, the investigation could be carried by a team made of the checkuser and a trusted russian editor.
I absolutely agree that there is a language issue. Which suggests that we should do our best to have at least one russian-speaking checkuser. But would it be more reasonable to have one russian-speaking checkuser with overall activity over all russian-speaking projects plus the serbian ones because he would also speak serbian
or one checkuser in ru.wikipedia, one in ru.wikibooks, one in ru.wiktionary, one in sr.wikipedia etc...
ant
--- Anthere Anthere9@yahoo.com wrote:
What that suggest me is this
We should not have checkusers with the tool access on a one project/one language, but a POOL of COMMON checkusers. Those should all have good technical abilities. Those would have access everywhere. They would be listed on meta with their language ability. The biggest projects would be used to always ask to their favorites. The small languages will try to find the one with a basic knowledge of their language if they wish.
But all in all, checkusers should be a common good, just as our developers right now are (and, hell, just as your board members are).
Ant
I think this is a good solution also. I would also like to see people with current access have an option of joining the pool or not. That should preveent us repeating the problem of thinking we have people to help the smaller project on paper, but in reality no one has the time or else feels uncomfortable working with unfamilar projects. Honestly I am sure there are some members of enWP arcom who have access but do not have time to answer requests at large. I have never had an issue with working through someone else to get this information. I do not mind not having a local checkuser. However I would like to be sure that this pool will actually be made up people who are wiling to make themselves available. And I can understand how the very large projects do need dedicated checkusers for something like arbcom. So I think we need a policy that allows for a large pool of people to work checkuser at large along with some dedicated to projects. I know this sounds alot like the current policy. However the pool of checkusers should be larger and and full of more technical expertise than the pool of stewrads. Also they will be people who have explicitly offered to use their access for problems on small projects. So although it looks similar to current policy on paper, I think that it would have different results.
Birgitte SB
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
This is certainly correct in my case. You can make me feel bad by making requests to me personally, but you can't enlarge my time or energy.
Fred
On Apr 22, 2006, at 7:32 AM, Birgitte SB wrote:
Honestly I am sure there are some members of enWP arcom who have access but do not have time to answer requests at large.
2006/4/22, Anthere Anthere9@yahoo.com:
Now, people have checkuser status only on one project/one language. Just as if Brion had help ip checking on the french wiktionary, whilst Tim was dedicated to the english wikipedia and Taw to the polish wikibooks. It makes NO sense whatsoever. The *only* unigue advantage of the current system is to understand the language of the project the checkuser make the job.
Not just understanding the language, also knowing the community, including for example the background of the request. For example, I once (before I de-sysoped myself) did a checkuser on two Dutch users A and B, where B was believed to be a sockpuppet of A. Doing the check, I found that B was not A, but that he was identical to some other user.
I have chosen to report (to the sysops) about this outcome by saying exactly the above. I did not give the actual other identity of B (although later it came to be known through no action of mine), because he was not involved under his other name in the dispute in question. Someone who was not as well-versed might not know what issue the request was about, or whether simply saying that he was a known user would identify him, or even whether this other identity of B was the better-known one etc.
-- Andre Engels, andreengels@gmail.com ICQ: 6260644 -- Skype: a_engels
On 4/22/06, Anthere Anthere9@yahoo.com wrote:
And the checkusers with the technical ability... pretty much offer to help anyone who needs help.
I can't speak for all 59 people who have CheckUser access, but I must state that I don't "help any one who needs help". The culture on enwiki regarding CheckUser is to be pretty stingy about its use, and we don't use it without demonstrated good cause. I think we reject about 90% of requests.
I am much more likely to accept a request if it comes from someone I know to be reliable. Note that this does not mean all admins, as I don't know all admins to be reliable. Anybody else has to convince me that there is a basis for suspicion.
We should not have checkusers with the tool access on a one project/one language, but a POOL of COMMON checkusers. Those should all have good technical abilities. Those would have access everywhere. They would be listed on meta with their language ability. The biggest projects would be used to always ask to their favorites. The small languages will try to find the one with a basic knowledge of their language if they wish.
I think this is fundamentally a good idea, although I also think that the appointment of CheckUsers should come down from the Foundation, not up from member wikis; at the very least, every appointment should must also be approved by the Foundation or by some body set up by the Foundation for that purpose. And the Foundation absolutely must be in possession of identifying information for each and every CheckUser: real name, location, email address, preferably other means of contact.
Kelly
Kelly Martin wrote:
On 4/22/06, Anthere Anthere9@yahoo.com wrote:
And the checkusers with the technical ability... pretty much offer to help anyone who needs help.
I can't speak for all 59 people who have CheckUser access, but I must state that I don't "help any one who needs help". The culture on enwiki regarding CheckUser is to be pretty stingy about its use, and we don't use it without demonstrated good cause. I think we reject about 90% of requests.
I am much more likely to accept a request if it comes from someone I know to be reliable. Note that this does not mean all admins, as I don't know all admins to be reliable. Anybody else has to convince me that there is a basis for suspicion.
I agree here; we tend to be careful with what requests we run. I think, however, that Anthere was referring to some of our recent comments, rather than our proclivity to run particular requests; that is, Kelly & I have been saying "We'd be happy to do checks for other wikis if we had access to do them," and Anthere's comment is in relation to this, that we are willing to help any other project that needs us if given access.
We should not have checkusers with the tool access on a one project/one language, but a POOL of COMMON checkusers. Those should all have good technical abilities. Those would have access everywhere. They would be listed on meta with their language ability. The biggest projects would be used to always ask to their favorites. The small languages will try to find the one with a basic knowledge of their language if they wish.
I think this is fundamentally a good idea, although I also think that the appointment of CheckUsers should come down from the Foundation, not up from member wikis; at the very least, every appointment should must also be approved by the Foundation or by some body set up by the Foundation for that purpose.
I don't have a problem with requests coming from Arbitration Committees; I think that qualifies as a "body set up by the Foundation" and the current policy would qualify AC's as "for that purpose." I don't think the Board has the time to handle all requests; as I understand it, they don't even oversee the creation of new developers, but rather leave that to the existing root-level developers en banc.
And the Foundation absolutely must be in possession of identifying information for each and every CheckUser: real name, location, email address, preferably other means of contact.
Obviously, something I'd disagree with, being rather committed to not ending up with my personal information on an attack site (as happened to a good friend of mine from Wikipedia this past week), nor do I want my wiki contributions to end up on my employer's desk (as also happened to my friend, and is the reason he is no longer a Wikipedian). If it comes down to having to submit to losing my career or keep working on this project, as much as I love Wikimedia, and as dedicated as I am to it, I'm afraid I'll have to go. I just can't afford to lose everything I've spent my life obtaining in order to chase sockpuppets, nor, considering some of the mentally unstable individuals we attract, do I wish to put my life and the lives of people I love in danger. As long as I can help this project without having to put my life or career in jeopardy, I'm more than willing to do it, but the day I have to say "My life's work and indeed my life itself is less important than Wikipedia" is the day I need to get out of it entirely. I'd venture to guess that there are a significant number of other users who feel the same way.
Essjay
http://en.wikipedia.org/wiki/User:Essjay Wikipedia:The Free Encyclopedia http://www.wikipedia.org/
Anthere wrote:
And as a result of this mix-up... because of the need to "trust" the checkuser, we have zizanie (does that exist in english ?). We have internal fight and rancor).
Larouse first describes this as "discord" but the French word "désaccord" seems very weak; it lacks the nuances of "zizanie". Perhaps "stir things up" works. The idea that a problem was started where there was none before does not easily translate into English. Does this help?
Ec
wikimedia-l@lists.wikimedia.org