In T416388#11583354, @Superpes15 wrote:

Actually I need a specific date, it cannot be granted for a long I need a specific date time, as mentioned it's an exemption that affects the creation of users on a daily basis (and edits on a minute basis) and would lose its usefulness if used longer :)

In T416388#11582836, @Superpes15 wrote:

Hi @OJJ, account creation is currently set to 6 new accounts per day from a single IP. I wouldn't feel comfortable granting a long-term exemption in general, and obviously this procedure is intended for single/full-immersion events and not for long-term use (as it also increases the edits/per minute limit for newbies and since the creation limits are per day). If there's a specific day on which accounts are created, you can specify it. Otherwise, you can use manual creation as a sysop onwiki. There are 10-15 participants, so I don't see the need for a long-term exemption, especially on a /24 IP range! Thanks for your understand :)

In T353049#9802834, @KartikMistry wrote:

In T353049#9800969, @Jklamo wrote:

I have tried the second thing, I have translated an article as autopatrolled and the (Machine translation) limit has not been applied. So this is working properly.

Thanks!

In T353049#9721780, @Pginer-WMF wrote:

In T353049#9712546, @Jklamo wrote:

The discussion was based on the real experiences of users and administrators. In my opinion, this is more meaningful than just analyzing statistics. Specifically, your statistics will only take into account the deletion of the article, not the low quality of the output, which requires extensive editing by experienced editors.

I agree that stats don't tell the whole story, and it would be great to have reliable measurements about quality beyond deletions. I was trying to provide additional context by surfacing some stats that may be harder to collect for some people in the community. As I mentioned in my comment (T353049#9414927) "Overall the proposal seems likely to have a positive impact in terms of the quality of the translations produced" so it is consistent with the experience reported by the editors. We'll apply these changes, but it is important for us to use these opportunities to learn more in detail which are the issues that communities face to make the tool better for Czech and the other 300+ Wikipedias where the tool is available.

In T353049#9712546, @Jklamo wrote:

In T353049#9414927, @Pginer-WMF wrote:

Thanks for the clarification. For some reason, I was thinking on "Extended confirmed users" which are based on edit count instead. In this case, it may be useful to compile some stats about the percentage of current translators that are autopatrolled and the differences in deletion rates for the translations they create.

Please be respectful of the discussion that took place, the result of which was a clear consensus (autopatrolled). Delaying a request has a negative impact on the experienced (high Machine translation limit)

The discussion was based on the real experiences of users and administrators. In my opinion, this is more meaningful than just analyzing statistics. Specifically, your statistics will only take into account the deletion of the article, not the low quality of the output, which requires extensive editing by experienced editors.

In T353980#9425146, @Urbanecm wrote:

As of now, this is not really actionable. From the description and the voting, there is clear consensus on introducing autopatrolled and patroller user groups at skwiki, which can be done. However, it is NOT clear who is supposed to be granting and revoking those groups (by default, it is stewards only, which is likely not intended) .

The description says the community is "slightly leaning" towards admin granting. This signalizes it is not part of the community consensus yet. At https://sk.wikipedia.org/wiki/Wikip%C3%A9dia:Hlasovania/Autopatrolled, I can see bureaucrat-granting mentioned. Unfortunately, the voting misses a "summary" section, which would clearly say what the community actually agreed on.

The specific local politics for allocation these user-rights will be resolved at the skwiki community level subsequently.

Without having at least the technical aspect ready (which user group is responsible for granting those two new groups), it is not really possible to add the two new groups (or more precisely, it is possible, but only stewards would be able to grant them, which is not really useful). As such, I'm marking this as Stalled until this can be clarified.