Requests for comment/Tickets
What I see over and over again is the need for a ticket system for Wikipedians. And this need is a very broad need that, although it is no magic wand, I believe will solve many problems and allows much efficiency, usability and pleasure among both editors, administrators, beginning users and readers.
I've been thinking about such a feature (as an extension) for almost 2 years, but never got around any work on it.
Last summer during Jimmy's talk at Wikimania in Israel the idea got me going again. Jimmy talked about bots eating his edits that he shouldn't have been able to do in the first place (specifically regarding Merge requests).
What I'm proposing is a simple system (simple for the user) in which requests can be made for a certain action to be taken. Either because the user isn't able, not allowed or not confident in doing the action himself right now. The most common scenario will be actions that require certain user rights:
- User block/unblock
- Requests for deletion / undeletion review
- Protect/unprotect
- Requests for rights (reviewer, rollbacker, sysop, ...)
Other things:
- Complicated renames or merges
- Maintenance tasks
Any of those could be a component in the ticket system (which can be created on the by an admin). And anyone can create a ticket, pick a component. And depending on the component the request would have certain input fields. For example links to either one page, two pages and/or a link to a user account. A bit like BugZilla but much more simplified foreign key-like inputs for pages and users.
[edit] Cases
- This allows a sysop to easily get a list of open requests for action X.
- No need to do maintain complicated templates with subpages on project pages, weird bot archiving discouraging users. Sysops can instantly see how much work there is and where to get started.
- This allows people active in merging pages to be able to filter the requests
- Without the need to synchronize stuff from talk pages etc., the overview will be auto-generated without the need for synchronization bots that eat edits.
- Allows integration into a "Community dashboard"
- i.e. in addition to "241 unpatrolled edits", "2,510 wanted articles", "4,012 articles to be wikified" etc. there could be a section for queues specific to the user groups the user is a member of ("19 open unblock requests", "2 open merge requests", "7 requests for user rights", ..)
- Simple way for users to request things without the need to follow a million style guides and learning templates and finding what to write where and then do a bunch of stuff here and then placing some template there.
- For example, on Commons we created a Gadget (enabled by default) to nominate files for deletion. It involves doing half a dozen API requests, substituting a bunch of templates and in the end ends up saving edits to 3 different pages. How did that ever happen ? No administrators get behind schedule all the time if we have to spend too much time with the wikisyntax and have no time for actually handling the cases and communicating with users.
- Easier integration in countervandalism tools
- Although with the coming of better patrol tools and this ticket manager there will likely be less need to externally access arbitrary statistics like "number of blocks a user had" or "warning level of user X". Even that would become a lot easier (no need to maintain a User_talk:Example/blockmsgs)
- Simple way to request user rights (through a visual form as well as automated through the API)
- Imagine when we have Special:RCPatrol, it could have a one-click button "Request patroller right"
- or with Gadgets "Request membership of gadget artists group", simple as that. Once you assume the request system exists, it's sometimes hard to imagine how it's currently done - if one wouldn't know any better.
[edit] See also
These blog posts reminded me (Krinkle) of this idea and inspired me to finally write up this RFC
