Wikipedia:Bot Approvals Group/nominations/Rcsprinter123
From Wikipedia, the free encyclopedia
- The following discussion is preserved as an archive of a request for Bot Approvals Group membership that did not succeed. Please do not modify it.
BAG Nomination: Rcsprinter123[edit]
- Rcsprinter123 (talk · contribs · count · logs · page moves · block log · edit summaries)
I am an operator of RscprinterBot for a few months now, I have also been active at various BRFA discussions since then. I'd like to exercise my judgement a little further by approving for trials and such things, and here you can see a link to all of the BRFA related pages I have edited. I think I have good judgement on the approval of bots, good knowledge of all the rules surrounding them, and to always ask good questions about any issue I can see before approving it. Rcsprinter (speak) 12:53, 1 January 2012 (UTC)[reply]
Questions[edit]
- Is BAG/BRFA broken? Why/why not?
- When should a request be speedily approved?
- BRFAs are by far one of the longest discussion/approval processes on Wikipedia (sometimes taking several months to complete), is this a problem? Do you think anything can/should be done to fix this?
- If you could change anything about BRFA/BAG, what would it be and why?
- Favorite programming language(s)?
- Favorite book and why? (or movie, if you don't read)
Don't feel like you have to answer all/any of them. Just curious to see your thoughts --Chris 11:18, 2 January 2012 (UTC)[reply]
- I think a request should be speedily approved if it is an interwiki bot which is very simple and like all the others, or if it is a simple, non controversial task which is agreed needs doing but doesn't need much discussion, like maybe creating daily maintenance categories etc.
- I never knew they sometimes took several months, but I do think it's a problem if this is happening. Maybe to solve it there should be a set time, like 1 week for AfDs. If it isn't decided you could have an extended one or something similar to that.
- Nothing really needs changing about BRFA, I'm fine with it as it is, only there aren't that many new bots being registered on it, sometimes about a week apart, and business is pretty slow, comments get written quite a bit after the BRFA is filed. As for the BAG, that's OK too except half the members are pretty much inactive; I won't be!
- Probably Java, because it's quite simple, although my bot's in PHP and that was OK as well.
- I'm not going to disclose an answer for the last question, but note that it seems a little unusual for a BAG request.
- Those are my answers. I'll be happy to answer any more. Rcsprinter (constabulary) 12:39, 2 January 2012 (UTC)[reply]
Discussion[edit]
- Sorry to be the first, but I will have to go with an oppose this time. We've had some other candidates before with more BRFA participation and better presentation and even they seem to have gone into hiding. BAG's problem is activity really. I was on the fence on this nomination, but as indicated by the number of BRFA edits and your answers I think you need a bit more experience with BRFAs and usual issues; may be read previous ones (at least recent ones). I would probably have been in support if you hung out in BRFAs for a while and commented and then got nominated a few months later. BRFAs can get technical and editors start nitpicking very minor details and I would expect a nominee to show previous aptitude at seeing and commenting on these. — HELLKNOWZ ▎TALK 13:09, 2 January 2012 (UTC)[reply]
- I think H3llkn0wz, sums it up more eloquently than I ever could. Your lack of experience and edits at BRFA is very concerning, and your answers do not alleviate my concerns. So, I must oppose. (Also, the last question is not that unusual) --Chris 03:30, 4 January 2012 (UTC)[reply]
- I would support, really 90% of BRFAs are simply process, and while it is good to have BAG members who can deal with "fine detail" not all need to do so. Far more important is to get the basic workflow running, old hands can be called in for tricky situations. Rich Farmbrough, 05:14, 8 January 2012 (UTC).[reply]