Hebrew Wikipedia Community is approved the new Auto-confirmed days limit to "30 days" and 100 edits by vote (https://he.wikipedia.org/wiki/שיחת_ויקיפדיה:פרלמנט/ארכיון_62#יישום_החלטת_הקהילה_-_הגדרת_משתמש_ותיק)
wgAutoConfirmCount = 100
wgAutoConfirmAge = 30 * 3600 * 24
I would greatly appreciate your help.
Regards.
+1 to Amire80.
@chaim Could you share some background with us? What is the problem your community is trying to solve? Maybe we can suggest a better solution.
Unfortunately closing this Phabricator task as no further information has been provided.
@chaim: After you have provided the information asked for and if this still happens, please set the status of this task back to "Open" via the Add Action... → Change Status dropdown. Thanks!
Wow a year has passed :)
Sorry I did not turn until now to deal with it.
The problems that the community tried to solve:
Can you please explain what this mean in more detail? I'm not sure what "page transfer" is, for instance.
Also, please explain what kind of issues are you facing with protected pages.
PS: I'm resetting priority to Low, since this requires discussion, etc, and thus is naturally expected to take more time. Please do not change task priority unless you plan to work on it, see https://www.mediawiki.org/wiki/Phabricator/Project_management#Setting_task_priorities for details. Thanks!
The community has decided to allow the following actions only after 100 edits and 30 days:
Resetting assignee.
That's something that was mentioned in the task's original description already. Could you please explain what is the underlying problem that the community is trying to solve? That would help us to discuss that problem instead, and potentially figure out a better solution.
Thanks!
Ok, I'm just the messenger but I'll try to explain the community position.
The use of protection in the Hebrew Wikipedia is defined so that we use mainly a basic level of protection.
But there are still issues that the community believes need to be protected, rather than raising the level of protection, we prefer to lower the level of permissions for people at increased risk, and the community believes the risk goes down for users who have made 100 edits and 30 days have passed since signing up.
@IKhitron Can you check that I was not wrong?
How many pages are moved every week in the Hebrew Wikipedia?
Of these, how many are moved by people who made fewer than 100 edits?
Of these, how many are subsequently reverted to their previous title?
I have no answers to these questions, I believe there is someone who has the answers.
But i think the will of the community should be respected as it decided in the vote
I decided to do a sample test August 1-15.
Out of hundreds of page moved, 29 were performed by users over four days but under 30 days and / or 100 edits. Of these, 15 were deleted!
Over 50 percent, it seems to me that explains the position of the community .
Threw together a query to answer these questions, with data from the past year: https://quarry.wmflabs.org/query/58046. On average there were 25 page moves per week by new users out of 428 total moves (5.7%).
For comparison, on enwiki the numbers were 351/9612 or 3.65%.
Of these, how many are subsequently reverted to their previous title?
That can't be answered with a simple database query unfortunately.
For the record, I don't think this is an acceptable solution. You're showing an error message to any autoconfirmed user that doesn't fall into the "new criteria". If sysadmins approve the limit change, then the filter should be disabled until the proper limit is implemented. If they don't approve the limit change, the filter should be disabled all the same since it'd be just a loophole. At the very least, it should be possible to increase the autoconfirmed limits to match those of wikis with more restrictive config. But that filter still feels plainly wrong, no matter how I look at it. IMHO.
The tale for edits on semi-protected pages is similar https://quarry.wmflabs.org/query/58048: over the last 12 weeks, there was an average 100 edits by newer accounts out of 3930 edits to semi-protected pages per week (2.55%). These counts, and the page move counts, are approximate. Editors that had not made 100 edits at the time of the action but now have and pages that were protected at the time of the edit but now are not are not included (false negative). Pages that are now protected but were not at the time of the edit are included (false positive).
As far as that filter goes, I agree that it's a poor solution. It would be somewhat better were it restricted to only the actions at hand (page moves & edits to semiprotected pages) and used disallow with a relevant message instead of revoking autoconfirmed. It's still a poor solution compared to configuration changes.
I agree with others that setting the autoconfirmed variables that high is extreme. Autoconfirmed (the status) does not just affect page moves and protection levels, it also affects things like rate limits and CAPTCHA. Subjecting new users to CAPTCHAs for at least 30 days, in a language they might not speak (T7309), is likely to be disastrous for editor retention. Not to mention the accessibility consequences.
I think it would be better to create an extendedconfirmed group, give it move rights and a protection level, and autopromote at 30/100. While it would be possible to move editsemiprotected from the autoconfirmed group to another group, that sounds like a "historical reasons" problem waiting to happen.
@AntiCompositeNumber summarized it quite well. One of the other important things that autoconfirmed controls are rate limits. Accounts that are autoconfirmed can save up to 90 edits a minute, while the limit for non-confirmed users is much lower: 8 edits a minute. Even worse, rate limits for non-confirmed users are shared by IP address.
That’s already bad for many outreach activities (events where a group of users learn to edit collectively). Where only few days from reg are required, this affects only the first event. With the new rules implemented, that would basically make off wiki events aimed at newcomers impossible (at least, without manually confirming each and every participant).
Of course, it is technically possible to change all those things. However, the purpose of shared autoconfirmed concept at all wikis stands: to grant certain rights at reasonably similar conditions.
I feel that this request asks for totally repurposing how autoconfirmed works. There are other tools to prevent vandals who bypass autoconfirmed restrictions from vandalizing a page. Targeted edit filters and extended confirmed protections are intended for that.
@AntiCompositeNumber suggests to adopt extended confirmed protection. Your wiki does have something like it - the autopatrolled protection. If you wish, it shouldn’t be an issue to switch auto patrol protection with extended confirmed protection.
If I understand correctly, there are two suggestions:
@AntiCompositeNumber suggests to create a new group and transfer the move and editsemiprotected permissions
And @Urbanecm suggests base on AntiCompositeNumber suggestion to transfer the move and editsemiprotected permissions to the autopatrolled group.
The transfer suggestion is a bit problematic, because this permission is not given automatically, and I understand that the community wants these permissions to be given automatically but after the set time, so I think the new group suggestion is excellent and will meet the will of the community.
I suggests "Experienced user" (experienceduser) in Hebrew is "משתמש מנוסה"
@Daimona @AntiCompositeNumber I agree with you I adjusted the filter until a real solution
@Amire80 I did this in a semi-automatic operation, tested the previous version of 109 AbuseFilter against previous edits (look for green V) and counted manually.
You are interface-admin in HE@wiki and you have permissions for it
With all do respect, any other solution aside from what was asked by chaim and so decided by a formal vote, should be discussed within our community. If you refuse to uphold our community wishes, that's your prerogative; but it is not up to chaim, IKhitron nor Amire80 to initiate creation of a new user group, and further discussion at this forum isn't appropriate. We should explain the situation to our community, and present your suggestion. Perhaps our community would prefer some other route.
First of all, let me apologize for resubscribing you to the task. I really feel like I should leave a reply here, but to give you a chance to notice it, I need to add you back.
I do totally agree with that, and I respect communities's right to self govern. However, in certain cases, community might not have enough information or skills to come to a right solution that pleases all. That's absolutely okay -- not everyone needs to have a perfect understanding of how the technical stuff works - after all, it requires advanced knowledge.
In this case, I'm merely trying to be your advisor, and help design the best solution that would be wanted by your community, actually solve your problem and won't bring any unintended side effects. For that reason, I always want to understand the issue that the community tries to solve, so I can offer a better solution, or inform about disadvantages or side effects, if there are any. I think that is necessary to empower community to make informed decisions, and I also feel that doing so is part of my role in the technical community, especially since I often contribute in areas that involve direct communication with the communities.
Feel free to bring my suggestions to the wider community, so they can be discussed. I do not plan to implement any of them unless they were discussed. Sorry if that was not clear. I'm also happy to directly communicate at the local venue, and take my advice there. Due to language barrier on my end, I unfortunately would not be able to participate in a discussion in Hebrew (I'd be only able to passively monitor it via Google Translate), but I'm very happy to join an English discussion.
That being said, the original vote is almost two years old now – community opinion might be different now (both on its own and taking concerns raised here into account). We usually don't accept old discussions as a proof of consensus, because of the risk that they no longer represent community wishes well.
If you refuse to uphold our community wishes, that's your prerogative
At this point, nothing that I said above should be interpreted as a formal decision to decline a request (which also happens, but it is fairly rare). If that were to happen, the task's status would be changed to Declined (that did happen over a year ago, as there were unanswered questions, but the task is now opened again).
Instead, I'm trying to advice you and your community using knowledge that I have, to help you to make the best possible decision taking all information into account.
; but it is not up to chaim, IKhitron nor Amire80 to initiate creation of a new user group, and further discussion at this forum isn't appropriate. We should explain the situation to our community, and present your suggestion. Perhaps our community would prefer some other route.
I agree with most of what you said here, however, I do think that involving regulars in the technical community is important, to avoid coming to a new conclusion that would also have unintended side effects.
Usually, that is done by Phabricator discussions -- with some of the community members acting as ambassadors, relaying important information to both parties. That is helpful, as it allows me to participate in a language I can speak, while letting the local community to participate in their local language, without most community members needing to understand English.
I don't insist on using Phabricator, we can have this part of the discussion on wiki too -- I'd just need that part to happen in English (or Czech :)), to let me participate smoothly.
I hope my explanations make sense. If you have any further concerns, I'm happy to address them.
@Urbanecm Thank you for your elaborate reply. Please excuse me for my short comment.
As long as
I do not plan to implement any of them unless they were discussed.
holds true (assuming you mean discussed within our community), I don't mind any preliminary discussion.
I brought it up again to the community to decide.
Summary just to be clear:
@Urbanecm We are on the same page?
We have presented this idea to the community, and there is an absolute consensus for implementation.
@chaim That's fine with me. Could you please link the discussion here?
Also, please note that priority field should be only changed by people actively working on the task, product managers, technical leads or experienced technical community members -- not by users requesting changes. I'm setting it to Medium which I believe is an applicable value here. Thanks for your understanding!
Bzzzzt.
Wait.
Why these particular numbers? Why 30 days? Why not 15? Why not 60?
Please don't say "the community decided". Please explain why did you choose these particular numbers.
I'm definitely telling you "the community decided"!
All these discussions are relevant only within the community, here the place is only to implement what the community has decided.
I see that someone responded to you in a similar spirit to a post you wrote in a community discussion.
Indeed, this is the will of the local community.
This thread raised the question of how best to actually implement this will of the community. It was indicated that implementing this naively (i.e. changing the threshold for getting
autoconfirmed permissions) is too extreme and it was suggested to create a new level of permissions - extendedconfirmed. This was brought before the local community and there's a consensus that this indeed meets the desires of the community. So there should be no issue with actually implementing this new level of permissions.
Now, raising the question of what should be the threshold for this new extendedconfirmed permission is a valid question, to be decided by the local community. The current threshold requested by the community is 30 days and 100 edits (and these numbers were chosen after a lengthy debate and a community vote). If , at some later date, the local community decides to change this threshold, then we can request such a change. For now, please implement the change as requested by the community.
I think it would be helpful to explain why you are continuing to question this. Is there some actual problem that could arise if the numbers the communtity decided upon are used?
The community decided this without basing this on any metrics.
Wikipedia is a wiki. A wiki is a site that anyone can edit. It is reasonable to enact careful regulation to limit the full openness in a way that will balance openness and prevention of vandalism. The regulation that is proposed here is not careful: The numbers are random and unusually high. Is there any other wiki that limits moving pages and editing semiprotected pages like this?
If the numbers are not random and based on research, I'd like to see this research.
Also, no metric has been defined for measuring the success or the failure of this change. It's OK to want to reduce the number of edits that must be reverted, but once this is done, will anyone check that this change actually reduced this number? If this current community decision is based on nothing but intuition, then in two years someone will say "I feel that the current numbers don't work and that we need to increase them further, to 180 days and 1000 edits". This is supposed to be based on metrics and not on feeling.
Finally, reducing the number of edits that have to be reverted is not the only impact to check. The other impact to check is how many new editors stay as editors. If there are a lot of things that they cannot actually edit, why would they stay as editors? I might be wrong, but it's easy to prove me wrong by simply defining metrics, measuring the success or the failure, and then keeping this change if it's successful or reverting it if it's a failure. But currently, real success and failure have not been defined. "Implement the community decision" is not a success metric by itself.
The community decided this without basing this on any metrics.
The community decided this after a lengthy debate and a community vote. 66 Wikipedians have participated in that vote, and if you're looking for one reason theses particular numbers were chosen, there isn't a single such reason - there might be 66 different ones.
In the end, this is irrelevant. Not every community decision can or should be based on some external metric (in fact, the vast majority of the community's decisions are not). What matters at the end is that the issue was discussed - at length - and every individual came to their own conclusion as to the preferred threshold, and the community as a whole has decided.
Based on the questions raised in this thread this was brought again for discussion and received a clear consensus.
It's time to implement the local community's clear wishes here. A single user who doesn't understand the wishes of all the rest can't block an action desired by the whole.
@Urbanecm, is there any reason *not* to implement this, given the recent clear consensus in the local community?
In addition to what's been written before, I will point to https://meta.wikimedia.org/wiki/Limits_to_configuration_changes for a general better understanding of potential factors apart from mere consensus.
Of course there are changes which - regardless of community consensus - will not be implemented. I've reviewed the link you've provided and I don't believe this particular request falls within any of the examples given of requests to be denied.
However, this is a different matter: If, indeed, someone believes that the requested change here violates some policy, then it should simply be denied on that grounds, regardless of community consensus or rationalization. But, if the change itself is allowed (i.e. doesn't violate wikimedia policy), and correctly represents the community's wishes after a lengthy debate on the subject, then it should not be blocked due to a single user objecting to it until seeing a research to justify the community's decision making.
So, again: is there any reason *not* to implement the community's request here?
The main page of Wikipedia in every language: "Wikipedia, the free encyclopedia that anyone can edit."
This proposal is departing very far from the "anyone can edit" idea. No Wikipedia in any other language has numbers that are so high. The English Wikipedia has an "extended confirmed" group, which requires 500 edits, but it's configured differently from what is requested here, and its activity levels are incomparably larger than those of the Hebrew Wikipedia. I'm also not sure that it was based on good metrics (although maybe it was; I can try to check).
I'm not saying that everything must actually be open to everyone. As I wrote above, careful regulation of permissions by account age, number of edits, and other parameters should probably be implemented in various wikis, and they should probably be adapted to every language, according to the number of active editors, number of page edits, number of readers, frequency of reverting, etc. But these numbers must be calculated and not just decided by a vote.
This will still allow everyone to edit. But will set a different threshold for access to protected pages (which are few anyway and only by necessity).
The page Limits to configuration changes details what type of configuration changes will not be accepted because they contradict the rule of "Changes that make the wiki less open". This request change does not contradict that rule (nor any other rule on that page).
Again: if the very *concept* of this requested change violates a policy, say so and we'll be done with it (and no "research" or "metric" would be relevant). But it seems that the objection is just because you, personally, have not been convinced by the community's *rationalization* of the request.
So it's not that "this change contradicts a policy", but "I haven't been convinced you ask this for a reason I personally agree with", and that approach undermines the key value of letting the local community set their own rule (as long as they don't contradict another rule by the foundation). I point that the existing threshold (as well as other threshold on various wikis) were not all (if any) chosen after some research. Practically *all* other local community policy decision are done without an external study/research but based on debates, consensus building, and community votes.
Would it be nice to have some external research providing the mathematically optimal threshold? Of course. But we don't have that for *any* other threshold, and wikimedia's policy does not prohibit a community from changing the threshold needed for editing semi-protected pages or moving pages. The only policy/rule close to this is that a local community can't ask to limit a group's "edit" permissions, which is not the case here.
@Urbanecm, can you please help clarify if this requests is considered to flat out contradict a foundation policy/rule or not? If so, please let us know and this request can be closed as "can't implement". If not, please explain why the local community's wishes can't be met.
@Urbanecm (or anyone else tracking this ticket): Is there any response to the question above? Any reason to not implement the local community's wishes, after a consensus was reached supporting the option presented in this thread?
But why is it different, and why is it so much higher than in every similar language, e.g. Slovak, Swedish, Finnish, and Catalan, which have comparable numbers of speakers and active editors? (Comparable, not identical.)
The page Limits to configuration changes details what type of configuration changes will not be accepted because they contradict the rule of "Changes that make the wiki less open". This request change does not contradict that rule (nor any other rule on that page).
Again: if the very *concept* of this requested change violates a policy, say so and we'll be done with it (and no "research" or "metric" would be relevant). But it seems that the objection is just because you, personally, have not been convinced by the community's *rationalization* of the request.
So it's not that "this change contradicts a policy", but "I haven't been convinced you ask this for a reason I personally agree with", and that approach undermines the key value of letting the local community set their own rule (as long as they don't contradict another rule by the foundation). I point that the existing threshold (as well as other threshold on various wikis) were not all (if any) chosen after some research. Practically *all* other local community policy decision are done without an external study/research but based on debates, consensus building, and community votes.
It's true that these numbers were (probably) not set based on rigorous research. But it's bad. Why not start basing it on metrics now?
The real question is how will you know that this change achieves the goal. The goal is not supposed to be "to implement community consensus". The goal is supposed to be "to have a free encyclopedia that anyone can edit (while having a filter that automatically prevents the most obvious vandalism)". How will you measure that vandalism went down? How will you measure that the number of new editors didn't go down?
Maybe 100 is a good number that will cause the vandalism to go down and won't cause the number of new editors to go down. Maybe 200 is an even better number for that. This number should probably be different for each language, and it's quite possible that it should change from time to time. But it should be changed according to metrics and not according to random guesses.
Why? Because the local community discussed - at length - the pros and cons and has reached a decision. It's not based on external metrics, the same way *all other current thresholds* were not based on external metrics (neither local nor global).
It's the will of the local community to modify this particular threshold in this particular way, even if you personally objected to it (and you were the only one). If, at some theoretical time in the future, the community feels that this is not desired, the community (again) can discuss other threasholds and reach a new consensus.
Also see: Wisdom of the crowd.
The question remains:
If so: then simply state it (and link to that policy) and this issue can be closed and we'll be done here. Nothing more to do.
If, however, this doesn't violate a global policy, then the only other relevant question is:
Yes, and all other current thresholds are not very good either, because they were also not based on metrics. Sooner or later somebody should start basing them on metrics. Why not start now?
It may look like I'm concerned specifically with the Hebrew Wikipedia, but I'm actually concerned about all the wikis. If this change here is done, this will be yet another thing that perpetuates the bad practice of using arbitrarily-chosen limits, instead of something that is proven to be good for the editors.
Evidently, this requires wider discussion, so I raised it at the global mailing list: https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/thread/ONYNFNACK34LQLTBRHI6M56LBJHFBSKW/
There are already different thresholds used at different communities, giving different permissions.
The question you've asked in that other mailing list is not the issue at present here!
We are not discussing here "What should be the autoconfirmed age and article count in the Hebrew Wikipedia" (as you phrased it in that mailing list). The current request is:
The move and editsemiprotected permission will transfer from autoconfirmed group to extendedconfirmed.
Have to say this is a rare request as all site allows autoconfirmed user to edit semi-protected pages - sites enabled extendedconfirmed group usually create another protection level called extended protection.
I noticed that the link you provided contains a vote section where most users support this proposal - which means we could deploy this config change. However, I still think question raised by @Amire80 needs a reply here - is it possible to perform some query or statistical analysis which could prove the threshold for extendedconfirmed group you chose is ideal? Like the distribution of edit counts of problematic users, including edit and move action etc. Detailed distribution figure would be really helpful to illustrate your point.
Noting the workaround used by hewiki (filter 109 and מדיה ויקי:Block-newbie-edit.js) is causing some weird behaviour (T315539). I also think the proposed levels for autoconfirmed are excessive, but I'd personally rather see it done via site config than a hack. If the community wants extended confirmed instead, could we update the task description accordingly?