Wikidata talk:Requests for permissions/archive/2013

This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

Staggered re-elections proposal

We currently have 20 editors whose adminship is set to expire on February 8th, five on the 10th, one on the 11th, two on the 12th, five on the 13th, five on the 15th, and three on the 16th. That's a total of 41 set to end over a period of eight days. We're also likely to see a few more get the mop before the initial wave is over.

I believe that it would be unfair both to the community and to the candidates to have that many people run at once (again), however I believe that we should respect the deadlines that the Stewards placed. Therefore I propose that we make an effort to stagger the re-elections into four groups of 10 re-election RfAs each. I am proposing two schedules; one has each reconfirmation period last for seven days, and one has each reconfirmation period last for only five days. In either scenario, anyone who gets the mop after this post would run their period starting February 17. This would, unless the Stewards decide to fudge the dates a bit, likely mean that their adminship would actually expire during the reconfirmation proceedings. The sitting admins could volunteer to sit in earlier groups, or we could just do it randomly.

Note that this RfC has nothing to do with the standards of reconfirmations. If someone wants anything other than using the existing criteria for a regular RfA, they should start a separate RfC.

Seven day timeline

Jan 20 - Jan 26
Jan 27 - Feb 2
Feb 3 - Feb 9
Feb 10 - Feb 16

Five day timeline

Jan 28 - Feb 1
Feb 2 - Feb 6
Feb 7 - Feb 11
Feb 12 - Feb 16

Thoughts? Sven Manguard Wha? 03:00, 17 November 2012 (UTC)

Support 7 day timeline

• Second choice. Sven Manguard Wha?
• 2nd choice.--Jasper Deng (talk) 04:56, 18 November 2012 (UTC)
• Either is fine for me — Arkanosis ^✉ 10:46, 19 November 2012 (UTC)

Support 5 day timeline

• First choice. Re-elections should be pretty straightforward, I think. Sven Manguard Wha?
• 1st choice.--Jasper Deng (talk) 04:56, 18 November 2012 (UTC)
• 1st choice, provided that it is always seven days for a proper RfA. —WFC— 07:23, 18 November 2012 (UTC)
• Either is fine for me — Arkanosis ^✉ 10:46, 19 November 2012 (UTC)
• Either is fine with me, but this one seems to work. Ajraddatz (talk) 13:25, 21 November 2012 (UTC)
• This seems to "work", as others before me have said. —Theopolisme 22:46, 26 November 2012 (UTC)
• yep, this should work Lukas²³ ^talk in German ^Contribs 23:40, 27 November 2012 (UTC)

Comments

• Don't we still have all of December too where admins will have to undergo a reconfirmation RFA three months later? If that's the case, I'd rather see how many administrators we have to do re-RFAs before a schedule is made. If it's around the same number we have including all the requests that are currently active, I'd support a 5-day schedule. However, if the number of admins we have to stand re-RFA doubles (or triples), I'd support a 7 day schedule first. Regards, — Moe Epsilon 05:08, 18 November 2012 (UTC)
  • I might expect the # of admins we have to roughly follow a logistic growth pattern, and I think we're getting close to carrying capacity (I expect us to have about 50-60 admins after this wave is over). I support 7 days simply because 5 days is a little short.--Jasper Deng (talk) 05:16, 18 November 2012 (UTC)
    • My observation is that the number of open RfAs has dropped steadily, so yes, we're going to have more admins appointed, but likely not another 10 after the 16th and before the 20th/22nd, so we're not going to have to worry about scheduling reconfirmations early for the ones that get appointed from now going forward. My concern is only in preventing a massive flood of reconfirmations all at once. Sven Manguard Wha? 16:53, 18 November 2012 (UTC)
      • True, and I might be wrong about our place on a logistical growth curve (which is a very reasonable model to follow).--Jasper Deng (talk) 19:19, 18 November 2012 (UTC)
        • I think a week is the most fitting considering there are many users who have appointed currently varies with time. Wagino 20100516 (talk) 13:49, 21 November 2012 (UTC)

Schedule

It looks like the five day schedule has the most support. Now all we have to do is get who will be reconfirmed in what order and where will it be handled. We could place it under a section in RFP. As for the order of those to be reconfirmed, I've taken a look at m:SRAT, and created the following schedule:

I've only done the first three cycles, the fourth one isn't done yet. There will need to be more cycles. I've placed the users so that their temporary adminship doesn't expire during the reconfirmation. I've tried to keep it to 10 per cycle, however that will not possible all the time. Feel free to change it or add new cycles. Techman224^Talk 00:17, 14 January 2013 (UTC)

Looks good, thanks for making this. I was planning to get around to it... sometime... :) Ajraddatz (Talk) 00:36, 14 January 2013 (UTC)

Is it some how possible to link to the adminlogs too? --Sk!d (talk) 00:38, 14 January 2013 (UTC)

Good idea, done. Ajraddatz (Talk) 00:40, 14 January 2013 (UTC)

Should the vote start automatically or should every admin start his own vote? Maybe we could notice them a week before. --Sk!d (talk) 01:01, 14 January 2013 (UTC)

It should start automatically but I think the admins should each provide a statement on why they should be reconfirmed.--Jasper Deng (talk) 01:05, 14 January 2013 (UTC)

If the admin doesn't respond, what should we do? Also, are we using the same standard as a normal RFA? --Rschen7754 01:27, 14 January 2013 (UTC)

It makes sense to use the same standard as normal RfA. Admins who don't respond simply don't get their adminship renewed.--Jasper Deng (talk) 01:45, 14 January 2013 (UTC)

Alternative schedule

This is what it would look like if we added a fifth five day long block, and have nine people per block. If my math is correct, no one loses adminship before their reconfirmation.

Jan 23 - Jan 27	Guerillero, Wiki13, SarahStierch, Superzerocool, Romaine, Sannita, Restu20, Tpt, Merlissimo
Jan 28 - Feb 1	Sebleouf, Raymond, Emijrp, Arkanosis, Seewolf, Benoit Rochon, Hoo man, Sven Manguard, Lomita
Feb 2 - Feb 6	Grondin, Skull33, Jitrixis, Yiyi, ShinePhantom, Vituzzu, Ajraddatz, Jasper Deng, Zanka, Hydriz
Feb 7 - Feb 11	Yair rand, Pigsonthewing, Stryn, Wagino 20100516, Jdforrester, Leag, TBloemink, Koavf, Conny, Danny B.
Feb 12 - Feb 16	Raystorm, Kaldari, Bene*, Hosiryuhosi, Zolo, Bináris, CennoxX, Moe Epsilon, Igna

I also propose that we prepare the reconfirmation pages in advance, have the candidates make their statements (or indicate that they don't wish to run for reconfirmation), and just have a bot add them in as soon as the timer hits. If we do this, we should let all admins know that the pages exist ahead of time. Sven Manguard Wha? 03:35, 14 January 2013 (UTC)

I made changes to your table above, and added a few admins to the fifth round. Techman224^Talk 04:02, 14 January 2013 (UTC)

Under this schedule, where would the admins who were promoted late be reconfirmed? --Rschen7754 04:05, 14 January 2013 (UTC)

When their adminships expire. The point of this system is to prevent 30 RfAs from hitting at once. Sven Manguard Wha? 23:21, 15 January 2013 (UTC)

Looks good. --Stryn (talk) 05:50, 14 January 2013 (UTC)

We could link the prepared sites here. --Sk!d (talk) 08:32, 14 January 2013 (UTC)

Stewards mainly give temporary adminship to users on minor wikis with a small or a nearly non-existing community. This is not that kind of project (any longer). I do not know if we have a fixed definition of what kind of mandate we are giving our admins yet, but I do not think that matter. It looks like we have a community large and mature enough to make our own decisions. May I sugest that we ask the Stewards to extend all the temporary sysops on this project, and we administrate on our own when there is time to de-flag an admin? On svwp, we have to confirm 20-30 admins in 30 days every three month, and we hardly make it each time. Here, you are suggesting we have to confirm 50 admins in three weeks, that sounds more or less impossible if you want a fair result. Give it more time, please! -- Lavallen (talk) 11:33, 14 January 2013 (UTC)

This might be only happen two times now and later if we finished Wikidata:Requests_for_comment/Defining_administrators. There it looks like admins will get a permanent right. --Sk!d (talk) 20:49, 14 January 2013 (UTC)

• I like Sven's modifications, but I am hesitant about making them run over more time. I find that the more votes are open, the more apathy begins to happen, so I'd prefer to get them over with (rather) quickly. Ajraddatz (Talk) 13:32, 15 January 2013 (UTC)
  • This is also the reason why I supported a 5-day schedule.--Jasper Deng (talk) 18:10, 15 January 2013 (UTC)

One more alternate idea

So you know how all of the stewards stand for reconfirmation at once? Why not create a subpage with every admin elected in 2012, and have each one have a "retain" and "dismiss" subsection, and have them all run at once, from Jan 26 through Feb 8? That will prevent apathy, and get it all over with. It's a bot more crazy than 4X12 or 5X9, but Ajraddatz has a point (above). Sven Manguard Wha? 23:20, 15 January 2013 (UTC)

I think that would be more efficient. --Rschen7754 23:46, 15 January 2013 (UTC)

I like that idea.--Jasper Deng (talk) 03:01, 16 January 2013 (UTC)

Why not include all the temporary admins though? I'm just concerned about nobody noticing the reconfirmations that aren't included... --Rschen7754 03:04, 16 January 2013 (UTC)

 Oppose I am for a 5 days circle. --Sk!d (talk) 20:45, 16 January 2013 (UTC)

• Five day cycles are good IMO. Ajraddatz (Talk) 15:22, 19 January 2013 (UTC)

It's up!

See Wikidata:Administrators/Confirm 2013 and tell me what you think, please :) Ajraddatz (Talk) 15:51, 19 January 2013 (UTC)

We should inform all upcoming Administrators on there discussion page about this. Should they create a new section or a new site for there vote and link it or included it? --Sk!d (talk) 15:57, 19 January 2013 (UTC)

I was just about to inform the first batch :) - The section stuff should be sorted out, there are subpages for every circuit where they can create a section. Ajraddatz (Talk) 15:57, 19 January 2013 (UTC)

I currently do not see the option that an admin does not to be reconfirmed. If I read it, it looks to me that even of they completely ignore all notifications, the nomination page for them will still be created by someone, and the voting proceeds.--Ymblanter (talk) 20:08, 19 January 2013 (UTC)

Yes, same thing happens with steward elections. If someone doesn't even create their nomination, though, I doubt anyone would support. But still - someone could be on a vacation right now and not even see it. It isn't fair (IMO) to just summarily de-sysop anyone who can't make the nomination. Ajraddatz (Talk) 21:50, 19 January 2013 (UTC)

Permission for Bot.

I have already the flag for my bot to add descriptions. If I want create items or add sitelink, I must do a new request? --ValterVB (talk) 19:57, 14 January 2013 (UTC)

In my opinion, yes, so we can make sure it works before we approve it. :) --Rschen7754 20:01, 14 January 2013 (UTC)

I agree. --Yair rand (talk) 20:10, 14 January 2013 (UTC)

OK, now I'll do some "manual" test then I'll put my request in Wikidata:Requests for permissions. Thanks. --ValterVB (talk) 20:28, 14 January 2013 (UTC)

What is a successful translation admin request?

So our guidelines say nothing about what the threshold for a successful translation admin request is. Right now at least one steward is interpreting it as the same for adminship (8 supports and 75%). Is this what we want the standard to be? As far as I'm aware, that's considerably higher than the standard at Meta... --Rschen7754 04:23, 16 January 2013 (UTC)

I have no strong opinion in that matter, BUT, the RFP tells us: "RfP scheduled to end at 21 January 2013 21:25 (UTC)". I would offer Sörby any rights he is asking for instantly if he request that. But maybe we should consider how long such an RFP have to stay open in the future. -- Lavallen (talk) 12:10, 16 January 2013 (UTC)

I would say 5 days. I'm not really that picky about !vote counts for translation adminship but to make it as less a big deal as possible, I would say 5 or 6, preferably 7, should be the minimum. 70% seems to be a reasonable cut-off for support.--Jasper Deng (talk) 23:06, 16 January 2013 (UTC)

I'd say just a general guideline of five days and 70% support. It's not a big deal, and should be easy to get for those who need it. Ajraddatz (Talk) 00:11, 17 January 2013 (UTC)

Also, if an admin determines consensus for translation adminship, I don't think a steward should have objections, though that is just my opinion.--Jasper Deng (talk) 01:48, 17 January 2013 (UTC)

As long as we do not have any Crats of our own, we have to accepts that Stewards has opinions. That is one good reason we should have our own Crats in the future. -- User:Lavallen (block) 08:05, 17 January 2013 (UTC)

Then the question is whether it is a bureaucrat's or administrator's job to close translation adminship discussions.--Jasper Deng (talk) 19:46, 17 January 2013 (UTC)

On svwiki, where I have most experience, is it not a bureaucrat's or a administrator's job to close a discussion. As long as the result is obvious, and the rules give no room for interpretation, it can be anybodys job. If there is doubts in the result, the discussion is prolonged until it isn't anymore. If the result looks corrupted by puppets and newbies, the crats can choose to do nothing, but that is the only "power" a svwiki-crat has. -- Lavallen (block) 20:09, 17 January 2013 (UTC)

5 days and 70% should be fine.--Ymblanter (talk) 09:28, 17 January 2013 (UTC)

Yeah, sounds good. --Rschen7754 09:58, 17 January 2013 (UTC)

5 days seems unnecessarily long to me. Sven Manguard Wha? 06:47, 18 January 2013 (UTC)

Yeah. I would handle it like metawiki ("No fixed time limit for these requests is defined, and there are no particular requirements; if you provide a valid reason your request will be granted."). Every sysop could grant it to himself or to any other user if he has a good reason for having the rights. Vogone (talk) 18:38, 18 February 2013 (UTC)

Renaming request pages

I think that it would be good idea to rename permission pages. Now all requests are Wikidata:Requests for permissions/user name except Requests for permissions/bureaucratship/user name. I suggest that we rename Wikidata:Requests for permissions/user name to Wikidata:Requests for permissions/[RIGHTS]/user name. And [RIGHTS] is some of the following words: Adminship/Bureaucratship/Translation Adminship/Bot. --Stryn (talk) 13:06, 18 February 2013 (UTC)

Sounds reasonable.--Ymblanter (talk) 15:56, 18 February 2013 (UTC)

In that case, wd:Requests for permissions/Archives and its subpages shoud be updated. Thanks. --Eric-92 (talk) 18:28, 18 February 2013 (UTC)

 Support, though from a grammatical point of view I think it's simpler to just say administrator/bureaucrat/translation administrator/bot. If only because we'll probably have rollbackers soon, and that's a fairly awkward phrasing... Requests for permissions/rollbackership? — PinkAmpers&^{(Je vous invite à me parler)} 07:30, 19 February 2013 (UTC)

True, well, I support those names. --Stryn (talk) 07:36, 19 February 2013 (UTC)

I support PinkAmpersand's version of this. By extension, we could transclude the requests on the immediate parent pages of those requests (Wikidata:Requests for permissions/administrator), then transclude these on Wikidata:Requests for permissions. — Hazard-SJ  ✈  03:30, 20 February 2013 (UTC)

What if we moved the bot requests to a different page entirely? With rollbacker and confirmed flags coming, the page might get overloaded. --Rschen7754 03:33, 20 February 2013 (UTC)

Sounds like a good idea to me, though perhaps we could still have a collapsed transclusion of the bot page on the main RFP page? Sort of a "look at it if you care, don't if you don't." Anyways, since this seems like a fairly noncontroversial bit of maintenance, does anyone mind if I just go ahead and move the subpages around? — PinkAmpers&^{(Je vous invite à me parler)} 05:29, 20 February 2013 (UTC)

Feel free to do it :) --Stryn (talk) 05:56, 20 February 2013 (UTC)

Part of it is to cut down on the clutter and the page load times. --Rschen7754 05:57, 20 February 2013 (UTC)

Whew.  Done Think I got all of them (except for one premature, non-transcluded one that I'd prefer to deal with myself, if nobody minds). I also made some bold changes – splitting /Admininstrator and /Bot off into (trancluded) subpages, most notably. What do people think? — PinkAmpers&^{(Je vous invite à me parler)} 09:46, 20 February 2013 (UTC)

Thank for your work. Btw now Vote links does not work. Who want to fix those links? :) --Stryn (talk) 09:53, 20 February 2013 (UTC)

Open ended bot approval

Multichill is asking for approval to have his bot do... essentially whatever interesting or useful tasks he can come up with (hereby referred to as "open ended approval"). I'm not against that per-se, especially for users like him that can definitely be trusted with running bot tasks, but I do want there to be some way of the rest of the community keeping up with what's going on. Therefore I propose that for open ended approvals:

• The bot most have explicitly gone through a Requests for permissions where open ended approval is asked for
• Reasonably detailed, task-specific edit summaries are used when the bot makes an edit (for example "depreciating property P:1234" as opposed to "depreciating" or "housekeeping")
• If a task is going to make more than, say 500 edits, they need to note that they're doing it by dropping a note on this page (Wikidata talk:Requests for permissions) so that the community is in the loop
• If someone makes a good faith request that the operator to stop a specific task, it needs to stop until the issue is resolved

This will allow trusted bot ops broad latitude and won't slow operators down (much) while also making sure that the wider community isn't in the dark on what's going on.

Thoughts? Sven Manguard Wha? 19:32, 18 February 2013 (UTC)

Actually, this is an important point. I am not a bot owner, but the suggested requirements look reasonable to me as an outsider.--Ymblanter (talk) 06:48, 19 February 2013 (UTC)

For the most part I agree. If you get a bot flag it means "we trust you enough not to break the wiki". I assume when you require edit summaries, you mean if the software supports them ;). Otherwise all bots should be using good edit summaries.

As for coming here every time you want to make more than 500 edits, I don't think that should be practice. I think bot owners should know when they are making a massive run, and can stick it on the bots userpage or something. Chances are no one will even notice. And yes, I agree if someone asks a bot op to stop, they should stop. This should happen with standard approved requests as well.

As someone who has gotten a bot approved on enwp (very strict) and commons (lax), I must say I prefer commons much more. Legoktm (talk) 07:53, 19 February 2013 (UTC)

Lego + 1. 500 edits is not necessarily a big amount in automatic mode. Bot owners should always annonce the type of the work they are dealing with. (However some bot owners implemented automatic logging on their user page, see e.g. hu:user:BinBot/munka, but this is an extra work, not provided by frameworks.) Edit comments may be set run by run, but they may not always be set save by save. Bináris (talk) 09:32, 19 February 2013 (UTC)

What Legoktm said. Multichill (talk) 09:37, 19 February 2013 (UTC)

• I don't think that adding a lot of overhead to the bot approval and running process will be beneficial. Ultimately, it comes down to the bot operators making sure that their bots are working properly. Especially with how long the current system takes to approve a bot, we should be looking at how to simplify this process, not complicate it. Ajraddatz (Talk) 13:44, 20 February 2013 (UTC)
  • I'm willing to drop the third bullet, and make the second dependent on software compatibility. I am not willing to drop either the first or fourth, although it looks like no one has objected to those explicitly. Sven Manguard Wha? 07:23, 21 February 2013 (UTC)

Ajraddatz: How long does the current system take to approve a bot? I really don't know. Requests are just parking there, and there is no explicit rule. I think this system is already rigid and burocratic. In Hungarian Wikipedia bots make some test edits, and crats give the flag in a few days, and we have few problems with this flexible system. Once somebody has proved his/her reliabilty in other wikis and wants to work, should be supported and let work and not be forced to wait and wait. I think we should handle things in a flexible and normal way. Yes, if there are problems with a bot, it is just normal to stop it until the issue is solved and if this does not happen, admins may be asked to block it at any time. There is no need of a new rule for this. Of course, edit summaries should be filled out properly at any time by all contributors, either human or bot, this is quite a basic behaviour from a Wikipedian, this does not need a new rule again. The proposal may be summarized this way: behave like a normal Wikimedian. Bináris (talk) 13:52, 21 February 2013 (UTC)

You're preaching to the choir, Bináris - I completely agree. That's why I think that Sven's proposal is going in the wrong direction, and trying to add bureaucracy not remove it. What I think should happen is a three step process:

1. Create the bot account and list the task(s) it intends to do.
2. Make a reasonable amount test edits for each of the tasks. (Using common sense of course.)
3. Request the bot flag on the bot flag request page, after five days, if there are no specific concerns with the test edits that the bot has done, the request is closed and the flag is given.

If the bot op wants to make big modifications to what their bot does, then they re-request for the changes. But if the changes are small, or if they are already approved for use on other bots, another request is really pointless. How does that sound? Ajraddatz (Talk) 14:08, 21 February 2013 (UTC)

I agree on most what is said above here, but I have problems with open-ended permission without a time limit. This is starting to look like a burocrate flag and those we only give out for a period. So I suggest that for cases like this for highly trusted botowners that wants to play around and come up with new stuff, we put a timelimit on it. Basicly we can extend it to all botflags for all bots, but that is a lot of work, but for this special request we can do special things. Carsrac (talk) 14:27, 24 February 2013 (UTC)

This proposal of sven is this form not getting my vote as it very restricted and making rules for one or two botsrequest is a wast of time. Carsrac (talk) 14:27, 24 February 2013 (UTC)

I'm opposed to unconditional open-ended bot approval as this basically amounts to asking us to sign a blank check without knowing anything about the operator or how they understand local policies, and getting ensnared by the "golden handcuffs". The reason the English Wikipedia is so stringent about bot approval is because we've been burned by bad bot operators before, and there is a high potential for damage should similar bot operators take up shop here. Wikidata is more consequential than Commons in this regard - on Commons it's just tagging, here it's manipulating the actual data displayed on all language Wikipedias. I might support a proposal requiring operators to ask before making a bot run (but without the 7 day bureaucracy) and to be willing to stop the bot and fix issues if people complain. --Rschen7754 21:54, 26 February 2013 (UTC)

This actually sounds reasonable to me as well.--Ymblanter (talk) 11:56, 27 February 2013 (UTC)

Better subpage names needed

We have admin section, bot section etc. on this page but all sections have tha same name structure, e.g. Wikidata:Requests for permissions/Ymblanter. These subpages are instant archives and will be hard to guess later which of them is a request for bot flag, for adminship, for anything else and will be hard to review the titles. I propose the practice we use in Hungarian Wikipedia: Wikidata:Requests for permissions/Ymblanter (admin), Wikidata:Requests for permissions/BinBot (bot) etc. Bináris (talk) 07:08, 19 February 2013 (UTC)

#Renaming_request_pages :). I like more about my suggestion, but btw, we really need to change those names. --Stryn (talk) 07:15, 19 February 2013 (UTC)

Sorry, I have not noticed. That's an equally good solution. Both have to handle multiple requests (2nd, 3rd time etc.). Bináris (talk) 07:21, 19 February 2013 (UTC)

• We could always have Wikidata:Requests for permissions/permissionname/Username (number)? Ajraddatz (Talk) 13:45, 20 February 2013 (UTC)

  That would be best, I think. James F. (talk) 20:50, 20 February 2013 (UTC)

Rollbacker and confirmed flags now available

Thanks to Reedy (talk • contribs • logs), admins can now add rollbacker and confirmed to users' accounts. I've put up some common-sense guidelines in the relevant sections. Do people think they sound fair? — PinkAmpers&^{(Je vous invite à me parler)} 14:32, 22 February 2013 (UTC)

Thank you! These guidelines sound good to me. I have added sentence about vandal-fighting experience. Regards --Iste (D) 15:02, 22 February 2013 (UTC)

I've drafted Wikidata:Rollbackers. The only main difference I'm suggesting from En-wiki policy is that we allow the use of rollback on editing tests. People are a lot less sentimental about their contributions here, and summary-free undo is already widely used on link removals and bad descriptions. — PinkAmpers&^{(Je vous invite à me parler)} 15:11, 22 February 2013 (UTC)

Looks fine to me, thanks.--Ymblanter (talk) 16:52, 22 February 2013 (UTC)

Looks good. Ajraddatz (Talk) 18:20, 22 February 2013 (UTC)

proposal for bot testing and approval

Because of Bot's hug and fast effects on data we should ask each bot-master to have also another bot (confirmed user) with -test extension in name (i.e. user:Rezabot & user:Rezabot-test) to separate new requests from bot contributions (for who has flag for other requests)

bot-master should have at least 200 edits with the test one to approve Bot's request.▬ Reza1615 / T 09:37, 5 March 2013 (UTC)

"Wikidata useful" js tool and impact on recent changes

Recently I have discovered that the tool Wikidata useful allows a set of items from an English Wikipedia category to be populated with the properties on the current mainspace page you're on. For example if I populate Qnnnn about an album by artist X with "performer=X", I could then activate the script's function to populate all articles in "en:Category:Albums by artist X" with the same statement. This activity has the potential to flood recent changes, but it also helps builds the wiki a lot. Would there be support for knowledgeable users to request a bot flag for a related account so that they could make these semi-automated edits without affecting recent changes patrolling? Are there any other technical solutions short of a bot-flagged account? I for one would be willing to log my "runs" on a subpage for auditing purposes. If not, are there other ideas? We do need clarity on this tool's function one way or the other, because it's not really fair to reprimand users who don't "know better" for simply using it [1], as long as it exists. In the mean time I personally will not use it on categories that contain more than 20 items or so. Thanks. Espeso (talk) 17:13, 11 March 2013 (UTC)

archival?

Because this page it's very long I propose to move all closed discussions to the archive. I am wondering why this not happened already (by bot) --Pyfisch (talk) 15:34, 8 April 2013 (UTC)

Most discussions (requests for adminship, bureaucratship, translationadminship and bot approval) take place on subpages. The only requests which are really on WD:RFP are the requests for the minor flags. I do not see any backlog there, to be honest. Regards, Vogone talk 15:49, 8 April 2013 (UTC)

Sorry, I did not see that Wikidata talk:Requests for permissions/Bot redirects here. I mean the subpage for Bots. There are nine closed requests. Some are closed a week before. --Pyfisch (talk) 16:25, 8 April 2013 (UTC)

 Done. We really should have a bot archive them... :P Legoktm (talk) 16:34, 8 April 2013 (UTC)

Thanks! --Pyfisch (talk) 14:46, 9 April 2013 (UTC)

Property creator requests

Moved from project page

• I'm a little bit surprised. The Wikidata:Requests_for_comment/Restrict_creation_of_properties_to_some_users discussion was just closed yesterday and now we've already about three property creators. No discussion about how many property creators should exist, or if everyone should get this permission who is requesting it. Also I'm surprised how fast the already now existing property creators was elected. There was nearly no chance to vote against someone. Please don't elect that fast, including my request! --Nightwish62 (talk) 18:01, 8 April 2013 (UTC)
  • Ok, too late. I was elected also. I'm happy to get this permission but I don't agree that there is no longer voting time for requests. --Nightwish62 (talk) 18:04, 8 April 2013 (UTC)
    • The idea is that admins decide who gets the permission, much like rollback and autopatrolled, based on prior property experience. --Rschen7754 18:08, 8 April 2013 (UTC)
      • Yes, requests for property creation right weren't intended as community votes. Admins decide, whether someone is experienced enough for holding this permission. It is like autopatroll and rollback *hrmpf* no big deal. Regards, Vogone talk 18:14, 8 April 2013 (UTC)
        • Ok. And just for case, where is the right place to request to unassign the permission from someone? --Nightwish62 (talk) 18:24, 8 April 2013 (UTC)
          • Probably #Requests for removal of rights below. Legoktm (talk) 18:26, 8 April 2013 (UTC)
            • Uh, I didn't see that :). --Nightwish62 (talk) 18:50, 8 April 2013 (UTC)

Wikidata:Requests for permissions/Removal

I think this page can be renamed Wd:Requests for Removal. How you guys think about my idea?--DangSunM (talk) 00:03, 1 May 2013 (UTC)

I prefer where it is now, requests for removal is too ambiguous IMO. Ajraddatz (Talk) 00:07, 1 May 2013 (UTC)

Auto-archiving WD:RFBOT

Hi, I wrote a quick script that will auto-archive approved (denied/other requests will need to be done manually) requests on WD:RFBOT. If there are no objections, I'd like to set it up to run daily around 20:00 UTC so we can ensure the page stays clean and keeps moving quickly. Legoktm (talk) 08:52, 12 June 2013 (UTC)

 Support --Rschen7754 09:00, 12 June 2013 (UTC)

 Support ·addshore· ^{talk to me!} 12:17, 12 June 2013 (UTC)

 Great! – as an improvement, I'd suggest to archive only RFBOTs that have not been edited since 5-7 days. --Ricordisamoa 23:17, 13 June 2013 (UTC)

I don't see any advantage to that since they will be listed in the archive, plus RfBot moves pretty quickly, there's no reason to leave stale closed requests still on the page. Legoktm (talk) 01:04, 28 June 2013 (UTC)

Support much needed change in this area, good job. Ajraddatz (Talk) 00:28, 14 June 2013 (UTC)

 Done Legoktm (talk) 01:04, 28 June 2013 (UTC)

RFBOT status

I'm just throwing it out that my bot updates Wikidata:RFBOT/Status now.  Hazard-SJ  ✈  04:11, 30 June 2013 (UTC)

Looks great! Take a look at User:Addshore/Wikidata:Bots/Requests/Status which I drafted a while back! Any chance you could add a bit of colour to your table? :) Also any chance you could move it to Wikidata:Requests for permissions/Bot/Status? :) Also I have transcluded it on to the requests page to make the table more visible and to see what people think ·addshore· ^{talk to me!} 09:41, 1 July 2013 (UTC)

I like that draft :) I've moved the page, but as for the colour, that would mostly require human work as well, for as much as your shows at least ;) I could easily check if the bot has either been approved or is being discussed (AKA "open"), but without usage of templates (the easiest case), the bot couldn't easily judge whether it's in a trial, etc. Otherwise, I could try to recode the status page to use templates to represent the rows so such fields can be easily manually updated, with the bot leaving such values intact when updating the page. Those such templates would have the colors "built in", based on what is entered into the parameter(s).  Hazard-SJ  ✈  22:43, 1 July 2013 (UTC)

P373 (Commonscat) filling

Dear colleagues. Can anybody tell me if there already is a bot filling the P373 property from the {{commonscat}} templates in Wikipedia articles? If there is not, I'd like to implement this, and file a permissions request as soon as the code is complete. (Not started implementing yet, asking here to not reinvent some wheel.) Thank you. --Krd (talk) 11:17, 21 September 2013 (UTC)

I thought Multichill was doing smth like this, it might be good to check with him.--Ymblanter (talk) 18:19, 21 September 2013 (UTC)

It seems at least someone is already doing it. Thank you. --Krd (talk) 16:48, 23 September 2013 (UTC)

Encouraging open source principles for bots

Hi, I have left a proposal to encourage open source principles for bots. I would appreciate some input to know what bot operators think of this.--Micru (talk) 14:31, 18 November 2013 (UTC)