Wikidata:Requests for comment/RfP voting eligibility
An editor has requested the community to provide input on "RfP voting eligibility" via the Requests for comment (RFC) process. This is the discussion page regarding the issue.
If you have an opinion regarding this issue, feel free to comment below. Thank you! |
THIS RFC IS CLOSED. Please do NOT vote nor add comments.
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- consensus to introduce the following eligibility requirement for voters:
- Users must have at least 100 local non-automated edits in order to vote in an RfP.
- A user must meet the voting eligibility requirement before the RfP starts in order to vote in that RfP.
--Pasleim (talk) 15:05, 19 August 2016 (UTC)[reply]
Contents
Background
editA recent request for administrator access featured multiple votes by editors who had clearly been canvassed and had little to no local edits here. This is problematic because oftentimes, said editors had little active participation in our community and their votes were often "drive-by" votes. This is not the first time this has happened, though I will avoid naming specific examples out of respect to the candidates (out of 7 requests I know of where this happened, only 2 of them passed).
Participation in our community is especially important for RfP votes because we have rights such as property creator that are unique to us (and administrators are tasked with exercising and assigning that right). Currently, while bureaucrats have some discretion, any registered user can vote, sometimes making it hard to ensure that requests for permissions reflect the will of our community and not drive-by voters from outside, and it is often subjective whether a given vote should stand; hence I believe concrete requirements are needed. To this end, I am proposing to introduce an eligibility requirement for voters. This would not affect eligibility to request a user right - anyone can still request any local user right, except for the usual restrictions pertaining to CheckUser and Oversight.
These options are mutually exclusive, and therefore, it is highly encouraged to support at most one of them.
Option 0: Status quo
editThe current requirement: any registered user can vote.
- Restrictions are unnecessary. All input is welcome. --Vogone (talk) 06:52, 29 June 2016 (UTC)[reply]
- We don't have a problem that this would solve. In all past cases of canvassed requests, the canvassed votes have made no difference. Let's encourage participation instead :-) Ajraddatz (talk) 20:23, 29 June 2016 (UTC)[reply]
- This issue has not made any difference so far. Participation should be encouraged instead.--Snaevar (talk) 15:04, 2 July 2016 (UTC)[reply]
- As stated by those above, participation should be encouraged these proposed restrictions are quite disengaging and may prevent useful consensus. If you really wanted to you could discredit my !vote here as a "drive-by vote" which I really don't think would be helpful especially since some wiki's here go by the slogan of "the free encyclopedia." Another question is how effective are these measures are they really going to work as intended? Davidbuddy9Talk 22:50, 5 July 2016 (UTC)[reply]
- Given that the intention is to prevent voting on who gets (semi-)advanced permissions on this wiki by people who are unfamiliar with this wiki, then I think the option I voted for (100 non-automated edits) will have the intended effect. "The Free Encyclopaedia" slogan is irrelevant here - we are not restricting who can contribute to, read or reuse the content on this wiki. This is entirely about internal processes. Thryduulf (talk) 11:28, 6 July 2016 (UTC)[reply]
- Does that mean you have no faith in us evaluating the RFPs properly? --Vogone (talk) 21:16, 6 July 2016 (UTC)[reply]
- Most people who are new to the project will be evaluating the RFP candidates in good faith, but that is not true of everyone. In many cases as well, no matter how much good faith a new user approaches the request with, they will simply not have the experience necessary to know whether the person requesting the permission is a suitable candidate or not - particularly for the property creator right, which is unique to Wikidata, and adminship as the culture of its use here is quite different to at en.wp for example. This is less so for permissions like rollback which (in my experience) differ little in use and culture between projects but it is far simpler to define the suffrage for all RFPs together rather than individually and I see significantly less downside to restricting new users from commenting on rollback permission requests than I do from not erecting a barrier to canvassing. Thryduulf (talk) 23:13, 6 July 2016 (UTC)[reply]
- This may be true, but I referred to the role of bureaucrats whose task it is to filter such comments out if needed (evaluate RFPs in the sense of determining consensus). Until now, we did so without any issues (as far as I am aware of, at least nobody ever complained) but now there's an RFC which implies there is a problem with us doing this (and that alternative measures like a fixed edit count are required), and many community members are supporting it. This makes me wonder if we have done something wrong. --Vogone (talk) 23:31, 6 July 2016 (UTC)[reply]
- Most people who are new to the project will be evaluating the RFP candidates in good faith, but that is not true of everyone. In many cases as well, no matter how much good faith a new user approaches the request with, they will simply not have the experience necessary to know whether the person requesting the permission is a suitable candidate or not - particularly for the property creator right, which is unique to Wikidata, and adminship as the culture of its use here is quite different to at en.wp for example. This is less so for permissions like rollback which (in my experience) differ little in use and culture between projects but it is far simpler to define the suffrage for all RFPs together rather than individually and I see significantly less downside to restricting new users from commenting on rollback permission requests than I do from not erecting a barrier to canvassing. Thryduulf (talk) 23:13, 6 July 2016 (UTC)[reply]
- Does that mean you have no faith in us evaluating the RFPs properly? --Vogone (talk) 21:16, 6 July 2016 (UTC)[reply]
- Given that the intention is to prevent voting on who gets (semi-)advanced permissions on this wiki by people who are unfamiliar with this wiki, then I think the option I voted for (100 non-automated edits) will have the intended effect. "The Free Encyclopaedia" slogan is irrelevant here - we are not restricting who can contribute to, read or reuse the content on this wiki. This is entirely about internal processes. Thryduulf (talk) 11:28, 6 July 2016 (UTC)[reply]
- Canvassing is a separate issue to account age or use. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:17, 7 July 2016 (UTC)[reply]
- Hard rules are bad. Why not allow one user who has made 99 well thought edits but allow someone with 100 quick and easy edits. --Averater (talk) 10:49, 14 July 2016 (UTC)[reply]
Option 1: Autoconfirmed
editUsers must be autoconfirmed, as defined on our wiki, in order to vote in an RfP. This means at least 4 days' tenure and 50 edits in most cases.
- Support Jianhui67 talk★contribs 05:20, 25 June 2016 (UTC)[reply]
- Support -- Hakan·IST 08:27, 25 June 2016 (UTC)[reply]
- Support ChristianKl (talk) 12:50, 5 July 2016 (UTC)[reply]
- 2nd choice Support Deryck Chan (talk) 17:16, 6 July 2016 (UTC)[reply]
Option 2: 100 edits
editUsers must have at least 100 local edits in order to vote in an RfP.
- Support Deryck Chan (talk) 17:16, 6 July 2016 (UTC)[reply]
Option 3: 50 edits
editUsers must have at least 50 local edits in order to vote in an RfP.
Option 4: 100 non-automated edits
editUsers must have at least 100 local non-automated edits in order to vote in an RfP. This specifically excludes:
- Edits made as a result of page moves on other wikis
- Edits made as a result of page deletions on other wikis
- Edits done by script or bot of any kind
- Support Even when one is autoconfirmed, it may not be enough. 100 non-automated edits should provide that.--Jasper Deng (talk) 04:55, 25 June 2016 (UTC)[reply]
- Support it is very easy to achieve this level, but it does show engagement with the project and an understanding of its basics. Thryduulf (talk) 13:58, 25 June 2016 (UTC)[reply]
- Support Deletion/move allows to be autoconfirmed without even visiting wikidata and being part of it. And being high editor with wikidata game is not a good way to decide whether she is eligible for votes, imo. — Revi 15:14, 25 June 2016 (UTC)[reply]
- Support --Chris.urs-o (talk) 04:57, 26 June 2016 (UTC)[reply]
- Support Snipre (talk) 18:30, 27 June 2016 (UTC)[reply]
- Support this seems about right to me ArthurPSmith (talk) 19:09, 27 June 2016 (UTC)[reply]
- Support Although counting in some types of widar edits (for instance mix'n'match) might be an idea. On the other hand, I guess that someone who uses widar has done at least 100 manual edits first. Lymantria (talk) 10:00, 1 July 2016 (UTC)[reply]
- Support MisterSynergy (talk) 14:42, 2 July 2016 (UTC)[reply]
- Support --Rschen7754 17:18, 2 July 2016 (UTC)[reply]
- Support I would personally be in favour of x edits during the last y months, i.e. something to show that the user is an active user on Wikidata (and not someone who tried Wikidata a long time ago and hasn't been involved since - the policies and practices and even the data model change over time and I doubt that someone who has not been around for years has sufficient familiarity with current practices to judge a RfP). Since that's not an option, I'm supporting this option as the next best thing. Note that creating items and adding sitelinks can also be automated edits that require no knowledge of Wikidata's existence (via the "Add link" link in the local wiki's sidebar). As far as I can tell, in most cases it's not possible to determine whether those edits were done manually by the user on Wikidata or automatically by the "Add links" link. I would lean towards excluding those if it's unclear how they were created. - Nikki (talk) 22:57, 2 July 2016 (UTC)[reply]
- Oppose.
It's hard to define "non-automated" / "script" edits on Wikidata. Existing tools that are unclear:Thanks Jasper for the clarification.- Wikidata game?
- Kaspar?
- Resonator? Deryck Chan (talk) 17:15, 6 July 2016 (UTC)[reply]
- @Deryck Chan: "Non-automated" is quite clearly defined above: since all three of what you mentioned are scripts of sorts, they would be counted as automated.--Jasper Deng (talk) 20:53, 6 July 2016 (UTC)[reply]
- Regretfully, in that case I must oppose this proposal. Editing Wikidata via these tools require just as much human effort per edit as editing through the Wikidata item pages. I find it unreasonable to consider an edit of lesser value just because an editor chose to participate using a facilitated interface. Deryck Chan (talk) 08:52, 7 July 2016 (UTC)[reply]
- @Deryck Chan: This isn't about the value of edits or the amount of human effort needed to make them, it's about how well someone can judge whether someone should be given extra permissions. That is very difficult to quantify though, so no criteria we choose will ever be perfect, but I think this is about the best we can do. External tools generally focus on doing specific tasks rather than giving access to all of the features available here, the documentation is here and discussions take place here, so anyone who is genuinely interested in being involved with things like voting on RfPs is very likely to also make edits on the website (which quickly add up). Discussions taking place here also means that if you only edit via external tools and never use the website, you are very unlikely to be following discussions or take part in a RfP unless you were canvassed (which is what we're trying to avoid). - Nikki (talk) 14:43, 7 July 2016 (UTC)[reply]
- @Nikki: If that's the rationale, we should stipulate 100 edits outside of the Item: and Property: namespaces, because an editor doesn't interact with community processes any more when they edit a label or statement on wikidata.org than when they do the same using an external tool. Deryck Chan (talk) 18:18, 7 July 2016 (UTC)[reply]
- I think the point here is the user should be at Wikidata.org - not any of enwiki or commons or PetScan or Autolist. — Revi 05:07, 8 July 2016 (UTC)[reply]
- @Nikki: If that's the rationale, we should stipulate 100 edits outside of the Item: and Property: namespaces, because an editor doesn't interact with community processes any more when they edit a label or statement on wikidata.org than when they do the same using an external tool. Deryck Chan (talk) 18:18, 7 July 2016 (UTC)[reply]
- @Deryck Chan: This isn't about the value of edits or the amount of human effort needed to make them, it's about how well someone can judge whether someone should be given extra permissions. That is very difficult to quantify though, so no criteria we choose will ever be perfect, but I think this is about the best we can do. External tools generally focus on doing specific tasks rather than giving access to all of the features available here, the documentation is here and discussions take place here, so anyone who is genuinely interested in being involved with things like voting on RfPs is very likely to also make edits on the website (which quickly add up). Discussions taking place here also means that if you only edit via external tools and never use the website, you are very unlikely to be following discussions or take part in a RfP unless you were canvassed (which is what we're trying to avoid). - Nikki (talk) 14:43, 7 July 2016 (UTC)[reply]
- Regretfully, in that case I must oppose this proposal. Editing Wikidata via these tools require just as much human effort per edit as editing through the Wikidata item pages. I find it unreasonable to consider an edit of lesser value just because an editor chose to participate using a facilitated interface. Deryck Chan (talk) 08:52, 7 July 2016 (UTC)[reply]
- @Deryck Chan: "Non-automated" is quite clearly defined above: since all three of what you mentioned are scripts of sorts, they would be counted as automated.--Jasper Deng (talk) 20:53, 6 July 2016 (UTC)[reply]
- Support --Epìdosis 09:22, 10 July 2016 (UTC)[reply]
- Support --Jklamo (talk) 17:31, 30 July 2016 (UTC)[reply]
Option 5: 50 non-automated edits
editSame as option 4, but with a requirement of 50 non-automated edits rather than 100.
- Support--GZWDer (talk) 15:24, 26 June 2016 (UTC)[reply]
Please support only one of the following two options. The requirement to be enforced is whichever option is chosen above.
Before RfP start
editA user must meet the voting eligibility requirement before the RfP starts in order to vote in that RfP.
- Support This in particular would reduce the effect of canvassing. Note that if the existing eligibility requirement (being registered) is retained, this would mean users would have to be registered before the RfP starts to vote. This rules out canvassed users who don't have local accounts.--Jasper Deng (talk) 04:57, 25 June 2016 (UTC)[reply]
- Support obviously. This is also done in steward elections. If it is during RfP time, then there could be possible canvassing, which we are trying to avoid. Jianhui67 talk★contribs 05:18, 25 June 2016 (UTC)[reply]
- Support to reduce the susceptibility to canvassing per above. Thryduulf (talk) 13:59, 25 June 2016 (UTC)[reply]
- Support obviously. — Revi 15:14, 25 June 2016 (UTC)[reply]
- Support --Chris.urs-o (talk) 04:56, 26 June 2016 (UTC)[reply]
- Support--GZWDer (talk) 15:24, 26 June 2016 (UTC)[reply]
- Support Snipre (talk) 18:31, 27 June 2016 (UTC)[reply]
- Support definitely - also I would suggest anybody who doesn't meet the criteria for eligibility to vote automatically does not qualify as ready to be an admin or other privileged user here. ArthurPSmith (talk) 19:13, 27 June 2016 (UTC)[reply]
- Support Lymantria (talk) 10:01, 1 July 2016 (UTC)[reply]
- Support MisterSynergy (talk) 14:43, 2 July 2016 (UTC)[reply]
- Support --Rschen7754 17:17, 2 July 2016 (UTC)[reply]
- Support - Nikki (talk) 22:34, 2 July 2016 (UTC)[reply]
- Support ChristianKl (talk) 12:52, 5 July 2016 (UTC)[reply]
- Support Deryck Chan (talk) 17:12, 6 July 2016 (UTC)[reply]
- Support --Epìdosis 09:23, 10 July 2016 (UTC)[reply]
Before voting time
editA user may vote in any active RfP as soon as they are eligible, even if the RfP started before they were eligible.
- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:18, 7 July 2016 (UTC)[reply]
- Sure. Again, more participation is better to my mind. Ajraddatz (talk) 04:32, 21 July 2016 (UTC)[reply]
- Comment If someone participated illegitimately in some process, why were they counted in the first place, irrespective of whether they met some magic edit count criteria?--Anders Feder (talk) 11:03, 25 June 2016 (UTC)[reply]
- @Anders Feder: The requirements proposed here are necessary, but not strictly sufficient. For example, even if someone has met whichever requirement is set by this RfC, they will still be prohibited from voting if they're blocked or found to be a sockpuppet. However, the definition of "illegitimate" is otherwise not concrete and subjective, and hence, bureaucrats have very limited discretion to strike such votes.--Jasper Deng (talk) 16:50, 25 June 2016 (UTC)[reply]
- @Jasper Deng: Do they? Which policy prohibits them from striking such votes? As for "necessary", in which way is it necessary to preclude users who do not meet one of the criteria above, but who haven't been canvassed, from participating in RfP?--Anders Feder (talk) 16:57, 25 June 2016 (UTC)[reply]
- @Anders Feder: The success of an RfP was defined to be a concrete number of votes (at least 75% and 8 support votes for admin requests, for example), without regard to struck votes; it was made clear during the RfC's that limiting bureaucrats' ability to do that would limit the amount of drama over requests. And the requirements proposed here require all users who vote to have at least some experience with editing here, so that said votes are informed and best reflect community consensus.--Jasper Deng (talk) 18:35, 25 June 2016 (UTC)[reply]
- What it best reflects is the consensus among those willing enough to put up with the behavior of other editors long enough to stick around for the given magic number of edits. There is no law of nature that ensures that they are particularly informed of anything other than what is in the narrow outlook of their own motives for being here.--Anders Feder (talk) 19:15, 25 June 2016 (UTC)[reply]
- @Anders Feder: But said users will at least get familiar with the basics of our project, which is necessary to edit. During your first 100 edits here, surely you learned about what this project is about. That is what I want to see, at the minimum, in RfP voters.--Jasper Deng (talk) 05:10, 26 June 2016 (UTC)[reply]
- During my first 100 edits I've learned that not a single one of those who have stayed around here for more than 100 edits is the least bit more competent than someone who has solely edited one of the sister projects which depend on the quality of the database and collectively generates 100% of the revenue that keeps it running. We'll see how this arbitrary division of them works out.--Anders Feder (talk) 11:23, 26 June 2016 (UTC)[reply]
- We are not talking about the quality of the database here, we're talking about which users are competent to hold certain permissions on Wikidata not all of which exist in the same way (or indeed exist at all) on other projects. What matters for whether a user should have a given permission is how competent a user is in a Wikidata context, which is not necessarily at all related to their competence on another project. I know one user who was a very valued and competent admin on Wiktionary but who was seemingly unable to collaborate constructively on the English Wikipedia. If this was about property requests or something similar I would probably share your concerns, but this is entirely different. Thryduulf (talk) 11:53, 26 June 2016 (UTC)[reply]
- There are many users on other projects that aren't competent and I didn't suggest that there aren't. What I said is that you can't find a single person among those who would be included by the criteria suggested above who is more competent than all who would be excluded by them. And disadvantaging large numbers of those who are sufficiently competent over those who are not but merely meets some magic number of edits is not a recipe that ought to inspire too high expectations of success.--Anders Feder (talk) 12:27, 26 June 2016 (UTC)[reply]
- @Anders Feder: But you can't dispute that someone with more than x number of edits is more likely to be better acquainted with our project than someone who hasn't. Can you find an example of someone who is highly well-versed with our policies and processes but has less than 100 edits? You would be hard-pressed to find one. You ought to provide some concrete data to justify your assertion, just like I gave concrete data about RfP's affected by canvassing.--Jasper Deng (talk) 03:45, 27 June 2016 (UTC)[reply]
- There are many users on other projects that aren't competent and I didn't suggest that there aren't. What I said is that you can't find a single person among those who would be included by the criteria suggested above who is more competent than all who would be excluded by them. And disadvantaging large numbers of those who are sufficiently competent over those who are not but merely meets some magic number of edits is not a recipe that ought to inspire too high expectations of success.--Anders Feder (talk) 12:27, 26 June 2016 (UTC)[reply]
- We are not talking about the quality of the database here, we're talking about which users are competent to hold certain permissions on Wikidata not all of which exist in the same way (or indeed exist at all) on other projects. What matters for whether a user should have a given permission is how competent a user is in a Wikidata context, which is not necessarily at all related to their competence on another project. I know one user who was a very valued and competent admin on Wiktionary but who was seemingly unable to collaborate constructively on the English Wikipedia. If this was about property requests or something similar I would probably share your concerns, but this is entirely different. Thryduulf (talk) 11:53, 26 June 2016 (UTC)[reply]
- During my first 100 edits I've learned that not a single one of those who have stayed around here for more than 100 edits is the least bit more competent than someone who has solely edited one of the sister projects which depend on the quality of the database and collectively generates 100% of the revenue that keeps it running. We'll see how this arbitrary division of them works out.--Anders Feder (talk) 11:23, 26 June 2016 (UTC)[reply]
- @Anders Feder: But said users will at least get familiar with the basics of our project, which is necessary to edit. During your first 100 edits here, surely you learned about what this project is about. That is what I want to see, at the minimum, in RfP voters.--Jasper Deng (talk) 05:10, 26 June 2016 (UTC)[reply]
- What it best reflects is the consensus among those willing enough to put up with the behavior of other editors long enough to stick around for the given magic number of edits. There is no law of nature that ensures that they are particularly informed of anything other than what is in the narrow outlook of their own motives for being here.--Anders Feder (talk) 19:15, 25 June 2016 (UTC)[reply]
- @Anders Feder: The success of an RfP was defined to be a concrete number of votes (at least 75% and 8 support votes for admin requests, for example), without regard to struck votes; it was made clear during the RfC's that limiting bureaucrats' ability to do that would limit the amount of drama over requests. And the requirements proposed here require all users who vote to have at least some experience with editing here, so that said votes are informed and best reflect community consensus.--Jasper Deng (talk) 18:35, 25 June 2016 (UTC)[reply]
- @Jasper Deng: Do they? Which policy prohibits them from striking such votes? As for "necessary", in which way is it necessary to preclude users who do not meet one of the criteria above, but who haven't been canvassed, from participating in RfP?--Anders Feder (talk) 16:57, 25 June 2016 (UTC)[reply]
- @Anders Feder: The requirements proposed here are necessary, but not strictly sufficient. For example, even if someone has met whichever requirement is set by this RfC, they will still be prohibited from voting if they're blocked or found to be a sockpuppet. However, the definition of "illegitimate" is otherwise not concrete and subjective, and hence, bureaucrats have very limited discretion to strike such votes.--Jasper Deng (talk) 16:50, 25 June 2016 (UTC)[reply]