Wikipedia:Bots/Requests for approval/RFC bot 2
- The following discussion is an archived debate. Please do not modify it. To request review of this BRFA, please start a new section at WT:BRFA. The result of the discussion was Request Expired.
Operator: Harej (talk · contribs)
Time filed: 18:01, Saturday November 27, 2010 (UTC)
Automatic or Manually assisted: Automatic, Unsupervised
Programming language(s): PHP
Source code available: Once I finalize the changes to the script, I will post it to User:RFC bot/rfcbot.php
Function overview: To post on users' talk, asking them to comment on RFCs. The service is strictly opt-in via Wikipedia:Requests for comment/Comment duty.
Links to relevant discussions (where appropriate): Wikipedia:Bot requests/Archive 39#RFC input request bot
Edit period(s): Whenever the RFC bot adds a new entry to a list. This could be as frequently as every thirty minutes but in practice that is never the case.
Estimated number of pages affected: Depends on how much interest there is.
Exclusion compliant (Y/N): I would say it's exclusion compliant insofar as it's an opt-in service. People who don't want bots posting on their talk pages obviously won't sign up to have a bot post on their talk pages.
Already has a bot flag (Y/N): Yes
Function details: Whenever the bot adds a new discussion to an RFC list, it triggers a newly added section of code which will select someone at "random" from Wikipedia:Requests for comment/Comment duty. The comment duty page is divided up into the different RFC categories, so a user signs up for the section(s) in which he or she is interested. Based on the category of that new RFC, a user or multiple users is selected, depending on the number of users in that category. If there are five or fewer volunteers for a category, only one person is selected. Between 6 and 15, two are selected. Sixteen or greater, three are selected. A template message, {{Comment duty message}}, is posted to the selected talk pages. The idea is that people who do not want to keep track of an RFC list on their watchlist, and only want to comment occasionally, will have this as an option.
Discussion
editAs one can see from Special:Contributions/RFC bot and my sandbox, User talk:Harej test account, the code seems to be functional. Any other questions or ideas? harej 18:01, 27 November 2010 (UTC)[reply]
- I love this idea. It's kind of like WP:3O in that it brings in outside opinions to RFCs instead of almost exclusively topic-specific ones, plus it doesn't unnecessarily annoy anyone, as it's both opt-in and opt-out at leisure. =) --slakr\ talk / 21:40, 27 November 2010 (UTC)[reply]
- And actually, the more I think of it, it could end up making RFC proceedings more productive, as a whole. It makes it a lot harder for participants to scream "zOMG cabalz@!" at genuinely uninvolved editors when there's obvious evidence to suggest that their involvement in the RFC is the direct result of being randomly selected by a bot. --slakr\ talk / 21:48, 27 November 2010 (UTC)[reply]
The idea is good, the above points strong. Added myself to the test page. May I suggest that users can optionally choose the absolute maximum number of notices they wish to receive in a given time. My concern is that less active editors may be spammed with RfCs more often than they'd want during RfC-happy periods. Secondly, I think you need to better define how your "randomness" will work, as true random distribution may in extreme cases choose same editors several times and other editor no times. Do you keep track of who has and hasn't been messaged lately? Thirdly, will you attempt to contact more editors if no previously contacted editors and few other editors have made an edit to the RfC page? This one's particularly addresses messy, long RfCs were most editors would tl;dr. Perhaps editors could somehow indicate they are not going to comment on the RfC they were sent. And finally, I would really like to be able to choose more specific categorization, such as "video games" or "Japan", although this may be technically hard to achieve. Thanks for reading. — HELLKNOWZ ▎TALK 12:03, 28 November 2010 (UTC)[reply]
- Sorry about the wait. Let me put some things into perspective. While I haven't done an analysis of past trends, there is seldom more than a few new RFCs per day. Consider that on User talk:Harej test account, there were four new RFCs that day, then one new RFC the next. That is more or less the absolute maximum for a talk page to be messaged by the bot, given that the test account is signed up for all the RFCs and is the only account in all the different pools. If each category has 10-20 participants, and there is a new RFC for a given category once every 3-7 days, the messaging would be very well spread out. That being said, I would like to implement a "spam limit," but bear in mind that the more fields a user has to fill out, the more parse work the bot has to do and the more work a user has to do, and also that it probably wouldn't achieve much given what I said before. As for randomness, it is indeed as random as PHP's random number generator is. I suppose a rotation system would be fairer and I will work one in if I can. RFC bot doesn't keep track of who comments in a given discussion (it would be a parsing nightmare, given the various circumstances RFC tags appear in). Finally, going deeper than the RFC tag category is a degree of specificity which the bot is not set up to handle, but I would imagine such a thing working in conjunction with WikiProject boxes on a page (that is for a later request). harej 05:33, 29 November 2010 (UTC)[reply]
- Thanks for reply. I was brainstorming mostly, I do not know the actual RfC frequencies, cannot guess on possible number of participants, etc. In any case, I already said I think the idea is sound. The "spam limit" is probably the only part I feel strongly about. — HELLKNOWZ ▎TALK 10:16, 29 November 2010 (UTC)[reply]
Thanks Harej, this is really great to see. Some questions
- Can the request include the summary text the RFC creator provides (as seen eg at Wikipedia:Requests for comment/Biographies).
- Is giving editors the option of receiving requests by email completely impossible, a bit impractical, or something to think about later on?
- In the bot request I talked about a Category; one notable advantage of this over the list you've used is visibility; other users will see these categories on user talk pages and thereby find out about the approach. Can we do both, or switch to a Category system?
- naming: "Comment duty" I don't much like. "Comment invitation service" or the like would be preferable.
- What about Point 4 of my request (checking for talkpage templates) - something for later on?
- I'm not too worried about the "spam limit" but perhaps the bot could check for existing invitations on the user's talk page, and check the date of that invitation. But then deciding how to set a limit is difficult - different people will have different ideas, and it may vary over time for one person.
- New idea: could the invitation include a link to a "Sorry, won't participate" bot subpage to allow people to say "I'm not going to respond to this invitation"? That would allow the bot to try again with someone else, and also help keep track of whether people are responding.
Many thanks! Rd232 talk 14:17, 29 November 2010 (UTC)[reply]
May I suggest that the bot links the #section under which the RfC is placed? Some pages are really long and RfC may be in the middle somewhere. Additionally, the message seems to be very long and does not stand out as a bot edit very well. I may be extra picky here, but bot talk page messaging is generally hated and only the best messages survive to be read. For example, I read neither of the two posts on my page, merely clicked the wikilink in the title. — HELLKNOWZ ▎TALK 19:12, 29 November 2010 (UTC)[reply]
- "generally hated"?? - well anyway I've removed the wikilink from the header at Template:Comment duty message, as having it encourages people not to read the text. Rd232 talk 19:26, 29 November 2010 (UTC)[reply]
- That was a hyperbole. My point was that the message is very long and most of it the editors would already know, since they singed up for it in the first place. The wikilink in section title or a wikilink directly below the section is a necessity for easy navigation. My point is that these messages should attempt to be to the point and recognisable. — HELLKNOWZ ▎TALK 19:35, 29 November 2010 (UTC)[reply]
- Well the messages should be helpful for newcomers too (was one of the points I took from Wikipedia:Village_pump_(proposals)/Archive_66#Input_randomisation). Since we don't expect users, once the system is up and running, to get invitations that often, I don't think brevity is that important. And there are a number of long bot notifications which people haven't signed up for. Rd232 talk 20:47, 29 November 2010 (UTC)[reply]
- Those non-signed-for long messages are the ones especially annoying (what "generally hated" was targeted at). I am of course personally biased from designer perspective, but I'd prefer short and elegant over long and newbie friendly. I suppose we can wait and see, but I somehow doubt you will have many newbie sign-ups. How about the very first message being more elaborate? — HELLKNOWZ ▎TALK 20:59, 29 November 2010 (UTC)[reply]
- Later messages being short - that could work, but it would require the bot to track invitations. Maybe "short message please" could be a parameter in the list or category. To be honest I'd rather add a link to the invitation requesting user feedback on the invitation, and see how that goes. Rd232 talk 21:56, 29 November 2010 (UTC)[reply]
- I drafted a userbox, which adds users into a category: Wikipedia:Requests for comment/invitation userbox. Rd232 talk 12:38, 30 November 2010 (UTC)[reply]
- Those non-signed-for long messages are the ones especially annoying (what "generally hated" was targeted at). I am of course personally biased from designer perspective, but I'd prefer short and elegant over long and newbie friendly. I suppose we can wait and see, but I somehow doubt you will have many newbie sign-ups. How about the very first message being more elaborate? — HELLKNOWZ ▎TALK 20:59, 29 November 2010 (UTC)[reply]
- Well the messages should be helpful for newcomers too (was one of the points I took from Wikipedia:Village_pump_(proposals)/Archive_66#Input_randomisation). Since we don't expect users, once the system is up and running, to get invitations that often, I don't think brevity is that important. And there are a number of long bot notifications which people haven't signed up for. Rd232 talk 20:47, 29 November 2010 (UTC)[reply]
- That was a hyperbole. My point was that the message is very long and most of it the editors would already know, since they singed up for it in the first place. The wikilink in section title or a wikilink directly below the section is a necessity for easy navigation. My point is that these messages should attempt to be to the point and recognisable. — HELLKNOWZ ▎TALK 19:35, 29 November 2010 (UTC)[reply]
- Approved for trial (5 notifications). Please provide a link to the relevant contributions and/or diffs when the trial is complete. Proof of concept, were any more needed; then may I suggest that a lit of subscribers be acquired i.e. that Wikipedia:Requests_for_comment/Comment_duty be populated such that a proper trial can be prescribed :) Regards, and good luck with this potentially invaluable idea. - Jarry1250 [Who? Discuss.] 17:58, 3 December 2010 (UTC)[reply]
- I would insist on much shorter repeat messages. Having successfully received several, the talk page could use less clutter. — HELLKNOWZ ▎TALK 18:22, 3 December 2010 (UTC)[reply]
- The repeat messages are largely from pages being sorted into more than one category, so they go through the process... more than once. I'll find a way to deal with that. harej 18:31, 3 December 2010 (UTC)[reply]
- I would insist on much shorter repeat messages. Having successfully received several, the talk page could use less clutter. — HELLKNOWZ ▎TALK 18:22, 3 December 2010 (UTC)[reply]
Update: 7 December
editI apologize sincerely for the wait. With regards to Rd232's points:
- I am not exactly sure what you mean.
- I will think about it later on. It would be the kind of thing that works as a parameter.
- We should not switch to a category, since with a page, we have the added benefits of parameters. We can definitely have a user category, though, but it would not be for the bot's benefit.
- "Comment duty" is a nice succinct name, which is what led me to choose it. "Comment invitation service" is a bit long, but WP:CIS is available. Whatever name we end up choosing will simply be fantastic.
- Yes. One thing at a time. First I want a system that works.
- A more effective approach would be to log this in a database, so that the data is not subject to the whims of talk pages.
- This would be an awesome idea.
Hellknowz: The bot links to the #rfctag anchor, which should work regardless of what the section is called. The talk page messages themselves are not terribly long, in my view, but if they can be made to convey the same idea but in less space, then I'm all ears. Personally, I am not sure the box to the side is all that necessary.
In any case, I have been silent on this for a while due to various life and on-wiki circumstances. For the time being, I have turned off the comment duty system. When writing it, I did not expect that there would be demand for such a sophisticated system, but since there is, I shall deliver. That being said, I will probably be rewriting the entire bot code from scratch. I hope to deliver all these changes by January 1. In the meantime, I would say trial complete ( Trial complete.). harej 18:03, 7 December 2010 (UTC)[reply]
- I do not object to the very first message being long and wordy. I am concerned about successive messages being longer than a sentence, link to the comment duty page, and a signature. Regarding your trial, you would probably want an extended one after new year. — HELLKNOWZ ▎TALK 18:29, 7 December 2010 (UTC)[reply]
Thanks, Harej. Things worth doing are worth doing well, and take some effort, and yours is much appreciated, this could be a fantastic thing.
- On point 1: I'm looking at Wikipedia:Requests for comment/Biographies and the first item there is "Talk:Aaron Crow... Different IP editors keep inserting a (most likely utterly baseless) rumor that Crow is romantically involved with pop singer Ke$ha. I would just delete this without comment as uncited, but unfortunately, based solely on the Wikipedia edits, this rumor has been "scooped" by blogs. I'm 99% sure that I'm within my rights to just remove it on sight but I thought I would ask for a second opinion to avoid even the appearance of edit warring. Kansan (talk) 17:44, 7 December 2010 (UTC)". My suggestion is to include this RFC summary in the notification message.
- Point 3: with the template Wikipedia:Requests for comment/invitation userbox we can have parameters as well. I do think long term the template/category approach might be more manageable, because (a bit like the Signpost subscription page) editors who leave or drift away probably won't bother removing themselves from the list. So unless you want to go beyond just ignoring inactive users for notification delivery to scrubbing inactive users from the list, the list will slowly balloon.
- Point 4. We should be careful not to give a name that will be misconstrued and possibly engender resistance; brevity has to be weighed against clarity. And having a shortcut available is certainly an advantage (WP:CD isn't).
Rd232 talk 18:45, 7 December 2010 (UTC)[reply]
- A user has requested the attention of the operator. Once the operator has seen this message and replied, please deactivate this tag. (user notified) - Jarry1250 [Who? Discuss.] 11:49, 12 December 2010 (UTC)[reply]
- Request Expired. Mr.Z-man 04:18, 2 January 2011 (UTC)[reply]
- A user has requested the attention of the operator. Once the operator has seen this message and replied, please deactivate this tag. (user notified) - Jarry1250 [Who? Discuss.] 11:49, 12 December 2010 (UTC)[reply]
- The above discussion is preserved as an archive of the debate. Please do not modify it. To request review of this BRFA, please start a new section at WT:BRFA.