Requests for comment/Stewards' question: How to make your Wikimedian life easier?

From Meta, a Wikimedia project coordination wiki

The following request for comments is closed. Closing rationales and results offered section by section in bold. No implementations were required. Snowolf How can I help? 21:02, 17 June 2013 (UTC)[reply]


Stewards had short discussion at their list and came to the conclusion to start the discussion how stewards could help to make life of Wikimedians easier. It is mostly about small wikis and rules around them. The idea is to make those rules more simple and more accessible to editors of small wikis. Other ideas are welcome, as well. --Millosh 17:40, 19 August 2011 (UTC)[reply]

(Make your own suggestion inside of separate section.)

Why are there votes everywhere when there should be discussions ? DarkoNeko 03:44, 26 October 2011 (UTC)[reply]
Probably because there are very specific proposals... Seb az86556 04:02, 26 October 2011 (UTC)[reply]

Admin and bureaucrat permissions[edit]

As admin and bureaucrat permissions shouldn't be a big deal, I suggest next changes:

I appreciate your comments, but the question is not "How stewards could help other stewards?" or "How stewards could help Meta community?", but mostly about small wikis; and it seems to me that all of you belong to the first category :P --Millosh 16:51, 21 August 2011 (UTC)[reply]

    • Closing: while the discussion above was positive, no implementation was put into practice in a year and a half since the last active discussion happened, and the global community in a dedicated RfC has now approved and set inactivity standards hence making the implementation of this decision superseded anyway. Snowolf How can I help? 21:02, 17 June 2013 (UTC)[reply]

And to add one more thing: It would be good if stewards and Meta Wikimedians would be constructive and propose other ways for helping small communities by lowering bureaucratic barriers. --Millosh 16:54, 21 August 2011 (UTC)[reply]

  • There is not much of a bureaucratic barrier with userrights. The highest one is to get the wiki started, everything else is a piece of cake. More help for the small communities can be done by people from the WMF or a chapter giving them courses in how to attract more people to work on the wiki. That's what they really need first. If they succeed in this, the thresholds for sysop and crat votings are met much easier anyway and nobody will then have to deal with temp sysopships and stuff like that. So we don't need to change the bureaucratic efforts, but we need to solve the reasons why these communities are so small that permanent sysopship and cratship are not easily handed over. --თოგო (D) 13:27, 23 August 2011 (UTC)[reply]
    I agree completely: Apart from short-term crisis management, the most important way to assist small communities is to help them grow. Question: Where can I find course materials for the abovementioned classes? ~ Ningauble 14:14, 23 August 2011 (UTC)[reply]
    Well, I guess they don't yet exist... But you can always ask the Wikimedia Foundation if they have something. --თოგო (D) 15:47, 23 August 2011 (UTC)[reply]
    They do, see User:Zikos brilliant Manual for small and new Wikipedias. --Purodha Blissenbach 08:16, 14 September 2011 (UTC)[reply]
    That is some good stuff, thanks. I am not sure much of it will be helpful for my home wiki, which has seen a sharp decline in active contributors (and adminiatrators) during the last couple years, but I will mull it over. ~ Ningauble 13:40, 14 September 2011 (UTC)[reply]
    Yes, I agree to that help must be given to make the project grow up, and that it should be the first priority. But that does not imply we should not discuss about sysop and 'crat permissions. I personnaly feel the barrier with userrights on small wikis, because some rights have been granted permanently ages ago, and I can't remove them. It's useless to keep inactive privileged accounts, as this has only disadvantages. And I think this is the reason why now stewards grant temp access on projects with a small community. -- Quentinv57 (talk) 12:29, 26 October 2011 (UTC)[reply]

Global watchlist[edit]

  • A multiwiki watchlist would be very welcome... I'm sure that must be possible with some toolserver magic, and I know it is not a steward thing but I would love it so much... Effeietsanders 14:16, 19 September 2011 (UTC)[reply]
    People already requested me to create this kind of tool. But as you are the only one who can see your watchlist, any external tool won't be able to display your watchlist. The only options I see are :
    1. Giving your password to the tool so it can access your watchlist (I think that some TS policy forbid to ask the wiki password, but I don't remember exactly)
    2. Copy/pasting your watchlist on each WMF projects to the tool, but that imply the tool should store it for each users (and by the way, there are nearly 800 projects)
    3. Requesting developers to develop an extension that will be part of the MediaWiki interface
    4. Requesting a tool that will get every watchlists with the JS (don't know if we have the right to do that, anyway the script may take a long time to import the watchlists of every wikis, but that seems to be the best solution)
    If that's just to see if your user or user talk pages got edited, this tool may help you ;) -- Quentinv57 (talk) 12:16, 26 October 2011 (UTC)[reply]
    Well, how about the watchlist-token you may set on Special:Preferences#mw-prefsection-watchlist? That way you don't need the password! a×pdeHello! 13:12, 26 October 2011 (UTC)[reply]
    Yes, that would be very useful if I had the same token on every projects, but unfortunately that is not the case. And copy/pasting the token key of each projects is equivalent to the situation number 2 described above. -- Quentinv57 (talk) 13:17, 26 October 2011 (UTC)[reply]
    I already asked Quentin for an extension on the sul-tool to show new mail. Same probs. Question: The token causes the you have new mail message to pop up? I hoped that this would work, obviously it doesn't :(( Currently I rely on email notification and the python script readtalk.py. Both not really convenient for lazy people like me. --Hedwig in Washington 01:44, 27 October 2011 (UTC)[reply]
    • I believe this is proposed as future part of Echo and the new notification system, but in any case a Meta RfC hardly helps in implementing such a thing, users interested in the matter can contact the admin tools development team. Snowolf How can I help? 21:02, 17 June 2013 (UTC)[reply]

Block more aggressively[edit]

This isn't really to discuss a "rule" but more a comment (since it's an RfC).

It would be helpful for a lot of the smaller wikis if those with the ability to block would do so more aggressively when the vandalism/nonsense/junk comes from an IP that geolocates outside of the language-area (> how likely is it that an IP in Italy will actually contribute constructively to Udmurt or Inuktitut, esp when the first edit is "sup fuckers?"). I'd say block on sight in such cases, without warning. This will give the wiki in question a different reputation: "There are people who defend it aggressively, vandalizing isn't fun there."

Seb az86556 00:21, 26 October 2011 (UTC)[reply]

My experience is that our (read sv.wikisource) vandalism comes from IP's that already is blocked from a larger project. (read sv.wikipedia) - And when I have blocked on our project, they go on to other minor projects in the same group of languages.
Therefor it would be nice to have the possibility to block/delete on a group of minor wikis. - No, I am not interested in becoming a Global Sysop. My main interest is not to hunt vandals. -- Lavallen 08:54, 26 October 2011 (UTC)[reply]
Would be easier to simply request a global block. If the IP is only blocked on sv wikis, they can switch to other projects indefinitely as long as they're not banned globally. -- Quentinv57 (talk) 12:04, 26 October 2011 (UTC)[reply]
Hah. If people actually reacted... Seb az86556 13:03, 26 October 2011 (UTC)[reply]

Bot permissions[edit]

Some changes are discussed on Talk:Bot_policy#Concerns_about_automatic_approval.2C_a_proposal, but not a lot of people watch this page, so I think it would be better to propose changes here :

  • Auto approval should also require a local bot flag request which will be open for at least 7 days -- Quentinv57 (talk) 13:08, 26 October 2011 (UTC)[reply]
  • Global bots will get their global bot flag removed it they are inactive for a certain period of time
    Already adopted here. -- Quentinv57 (talk) 13:08, 26 October 2011 (UTC)[reply]
  • Local bot flags could be removed by stewards in the following situations :
    1. For every accounts that has got the bot status, if the wiki does not have local 'crats (or inactive) when the rights are removed (independently of the automatic approval)
    2. If the bot has been approved only to fix double redirects and interwikis and the wiki allows the bot automatic approval when the rights are removed (whether local 'crats exist or not, and whether the status has been given per automatic approval or not)
    Now, policies allows stewards to add bot status to accounts on wikis without local active bureaucrats and sometimes per automatic approval. In the first situation, only stewards have technically the right to remove the bot status, so that's the same as for the global bot status : if they do not remove it, it will never be done.
    In the second situation, the community has decided to implement the auto approval policy, and that's because they have decided to let stewards manage interwiki bots. Anyway, for this second point, we should re-implement the policy on every wikis. -- Quentinv57 (talk) 13:08, 26 October 2011 (UTC)[reply]

The first idea is a bit tedious. You should write "Auto approval on a wiki where there is activity other than bots..." — it doesn't make to force someone to post a request for 7 days when we already know there's no-one there to answer. Seb az86556 22:27, 26 October 2011 (UTC)[reply]

No it doesn't. But it will as soon as the bot flag is requested on meta. That's why you have to enter the link to the local discussion/BRFA page. --Hedwig in Washington 01:47, 27 October 2011 (UTC)[reply]
Well, that's what I mean. That rule should be scrapped or changed. Seb az86556 02:54, 27 October 2011 (UTC)[reply]
I'm not really supporting the first point, it was just an idea. But the way interwiki bots are managed should be changed, we should clarify it. I'm not sure that making people start a local discussion is the best idea, but if it's not, I don't see why some should do it and some should not. But personally sometimes I can't judge if the bot works only with 100 edits, moreover when they were all done the same day. -- Quentinv57 (talk) 08:46, 27 October 2011 (UTC)[reply]
The point is that you don't know if there's somebody to answer. How do you know? You have to post your request and find out. IMHO it should be 7 days (+) and 100 edits before meta flags any bot for interwiki or redirects. I know, there's pywikipedia-framework and it is running fine (most time) still no reason not to respect the wikis the bot runs on. It's a small duty for a bot master to c&p a BRFA on small wikis. On the big ones you have to do it anyway. Easy to say for me, I am done with all wikis. :-) --Hedwig in Washington 01:09, 28 October 2011 (UTC)[reply]
"how do you know?" You look at Recent Changes. It's that easy. Seb az86556 14:23, 28 October 2011 (UTC)[reply]
The first proposal looks like an attempt to abolish automatic bot approval. Automatic should mean automatic, without any discussion. The second proposal is just a solution in a search of a problem. Ruslik 09:35, 28 October 2011 (UTC)[reply]

Okay. But what do you think about the third point ? There is nobody to remove local flags on projects without local bureaucrats. Lots of people agree just above that stewards should be able to remove flags of inactive sysops and bureaucrats on small projects, and what's about bots ? They are even more dangerous, because nobody is monitoring them on those small projects.

  • Local bot flags could be removed by stewards in the following situations :
    1. For every accounts that has got the bot status, if the wiki does not have local 'crats (or inactive) when the rights are removed (independently of the automatic approval)
    2. If the bot has been approved only to fix double redirects and interwikis and the wiki allows the bot automatic approval when the rights are removed (whether local 'crats exist or not, and whether the status has been given per automatic approval or not)

Thanks -- Quentinv57 (talk) 14:29, 28 October 2011 (UTC)[reply]

Of course. That should simply be common sense... Seb az86556 15:37, 28 October 2011 (UTC)[reply]
Sorry, but I don't get your point!
If a local crat (or a stew if no local crat is available) removes the (bot) right, what flag is left to be removed?!? a×pdeHello! 16:58, 28 October 2011 (UTC)[reply]
No one. I just want to have the confirmation that stewards can remove bot flags for inactivity on projects where there is no local active bureaucrats. The second point is not that obvious, because it's not part of the actual auto approval policy, even if it is for me common sense. Do you understand what I mean, now ? -- Quentinv57 (talk) 17:05, 28 October 2011 (UTC)[reply]
(e.c.) Second one says (if the bot is granted under automatic approval but does something other than redirect/interwiki fixes) and the community still allows automatic approval at that time, the flag may be removed by stewards. --Bencmq 17:07, 28 October 2011 (UTC)[reply]
For the first point it is very straightforward - stewards are suppose to fill in the role when there is no local users around that are able to perform such action. That's what stewards do!. -Bencmq 17:00, 28 October 2011 (UTC)[reply]
Then let's face it this way: "Stewards are entitled to substitute local crats wherever local crats are missing or inactive!"
Sounds a bit more easy to me ;-) a×pdeHello! 17:08, 28 October 2011 (UTC)[reply]
Let's put the into the policy. :-) Nevertheless, I still think posting a BRFA on all wikis is courtesy, no matter if there is not much activity in the RC. There might be people just watching the RC. It could be made more automatic, maybe a bot running from the toolserver could do that after there's a note on a separate page, like: BRFA - low traffic wikis --Hedwig in Washington 17:39, 28 October 2011 (UTC)[reply]
Some wikis specifically allow automatic approval so as to avoid unnecessary bot requests. Forcing a bot request is sort of counter to the whole point of automatic approval. It stops becoming automatic if there has to be a discussion. -Djsasso 18:18, 4 November 2011 (UTC)[reply]
You got a point there. I just thought of the local BRFA as a courtesy call so people know, there's a new bot in town. :) --Hedwig in Washington 03:10, 6 November 2011 (UTC)[reply]

Global ArbCom[edit]

There are always talks about a global ArbCom. If not such a thing, at least -some- group that can look into disputes. After all, Stewards are supposed to "not decide". How about a group that can decide. This doesn't mean that I support such an idea, but people bring it up quite often. Ottava Rima (talk) 02:11, 27 October 2011 (UTC)[reply]

See the current discussion for a Global requests committee. Ajraddatz (Talk) 16:47, 27 October 2011 (UTC)[reply]
And Global arbitration committee and about a dozen other pages. :) Ottava Rima (talk) 21:15, 27 October 2011 (UTC)[reply]
All of those are old, though - the one I linked to is the current discussion (which I still bet won't go anywhere). A few people really just need to get together and make a plan for this, and promote it somehow rather than leaving it to barely-viewed RfCs and pages. Ajraddatz (Talk) 22:00, 27 October 2011 (UTC)[reply]
That statement can equally apply to 99% of proposals on Meta. :) Ottava Rima (talk) 00:05, 28 October 2011 (UTC)[reply]
Main article: Global AbuseFilter

As someone who has been tracking down spambots for a while (and, recently, deleting spam) I would like to see a Global AbuseFilter implemented. It would be invaluable for preventing spam like "Test, just a test/Hello. And Bye." and it would also enable trusted users to see the details of the abuselog. Just adding this because I feel it would make countervandalism activities (such as the SWMT) more efficient. πr2 (tc) 19:18, 20 December 2012 (UTC)[reply]