Talk:Requests for comment/Tickets/Archive

Feedback
Neat idea. I wonder if Flow will help with some of this.

I also wonder if it makes sense to tackle individual problems first before trying a unified system. Years ago Werdna (who's now doing Flow work...) wrote a prototype MediaWiki extension that focused exclusively on (voting) deletion processes. Taking discrete manageable bites like that might be a better path forward here. For example, a global gadget to allow for easily speedily nominating a page for deletion (or protection) is probably easy enough to implement. It requires a sane localization system within JavaScript and the ability to have global gadgets. We're... half there! Building on overall architecture (i.e., making something that can scale) such as global gadgets seems like it would indirectly move ideas like this forward. In other words, give people better tools and they'll make better products. Focus on the building blocks rather than the building.

Meanwhile a system for tracking voting deletion (or protection) discussions might involve aspects of Flow, Echo, watchlists, and other new technologies, probably more in PHP/SQL rather than in JavaScript.

Breaking down the overall communications problem discussed in this RFC into smaller bites seems like a better approach here, I think.

Krinkle: Any thoughts on next steps here? :-) --MZMcBride (talk) 02:22, 9 October 2013 (UTC)
 * A gadget like that exists on Commons. The problem with that is that it will always be based on wiki pages. Which are tolerable when input is through a different interface (gadget), and tucked away in templates. But when it comes to consuming the data (searching, discovering) or when trying to use it (e.g. assign status open/closed) or re-use it (e.g. display oldest open tickets for an admin to deal with, or show that a file is nominated on the File page itself) it hits a wall (you'd have to physically add it to those other pages where you want to display it, and have to do so at creation time, and remove it afterwards). This is a typical case where we've gone very far already within wiki pages (see Commons, Wikipedia). I agree that deletion is a good one to tackle first and build from there. However I think this is a perfect example of where the first step towards improvement is making it an actual process and not more wiki pages. Krinkle (talk) 18:44, 9 October 2013 (UTC)
 * The second thing I find most difficult to deal with is user block requests. Especially when dealing with cross-wiki vandalism I can never seem to find the right place to ask for a user to be blocked. With deletion at least I can pretty much rely on  working, and stewards/global sysops have a tool to search for those cross-wiki to process them if local admins don't notice them. But for user blocks we don't have something like that afaik (usually I just ask in #wikimedia-stewards on IRC, but that's not really a good process). It would be great if there was a Special page like this to deal with that. This would naturally be in my own user language. And it would naturally be possible to then query those cross-wiki (ideally integrated, but the cross-wiki part could be something a gadget or tool can do). Krinkle (talk) 20:12, 9 October 2013 (UTC)

Merge this with Flow?
As Max says above, I think this is worthy of development but is really something that should happen within the Flow system (which is planning to do many of the examples given in the lede). Would Maryana want to comment?

Jdforrester (WMF) (talk) 04:07, 5 January 2014 (UTC)


 * Yes – what you're proposing,, is effectively the workflow engine side to Flow :)
 * What Wikimedians need first and foremost is a simpler way to talk to each other; that's the discussion system aspect of Flow, and it covers the first few standard deviations' worth of use-cases across our projects (everything from content debates to bug reporting). But there are more sophisticated processes, like the ones you mention here, that also occur in talk spaces, and those require more structured software. In the process of working on the former, we'll create tools to solve the latter. For example, before Flow goes live in the user talk namespace for new users, we'll need to figure out how to deal with blocking/unblocking, and before it goes live on new article talk pages, we'll need to figure out how to deal with deletion. This may not be a fully-fledged workflow management system from the get-go, but we'll get there eventually :) Maryana (WMF) (talk) 17:50, 6 January 2014 (UTC)
 * I'm fine with deferring this RFC in order to give Flow a chance to fulfil the relevant needs. However I'm unsure whether it is within the appropriate scope of Flow to fully cover these use cases end-to-end, but – let's cross that bridge when we get to it. Also note that my underlying proposal for Tickets predates Flow. I first brought it up at the Wikimedia Nederland Hackathon 2011 (Amsterdam), and at Wikimania 2011 (Israel). Among other reasons, I've not focussed on this RFC because it does indeed look like Flow is going to take care of most (if not, all) of the workflow relevant to the idea of "request tickets" that users would create in order to request a group of users to take a particular action – such as proposing (un)deletion, (un)protection, splitting/merging of articles, and blocking, creation, etc., of users. Krinkle (talk) 18:57, 8 January 2014 (UTC)
 * Who's Max? --MZMcBride (talk) 21:54, 20 January 2014 (UTC)

After talking to Roan & Danny about this we had a general consensus of yes, we need something like this, but it can be built independently of Flow, and probably should so we don't end up bloating of Flow. I've "re-opened" the RfC and will expand on it. Legoktm (talk) 01:31, 3 June 2015 (UTC)

Just do it
If someone has the interest and motivation to do so, there is no reason for this to even be an RFC. This is certainly a useful extension so the only real value of this is to find some people to commit to creating it. Having used other non-wikimedia wikis for years, the very first annoying thing was it was strangely lacking tools with the ability to:


 * Warn - this can sometimes even be far more useful than blocking. The current workflow of having to put templates on talk pages is just crazy. There is no way to count the warns and no way to review them when blocking.
 * Delete - automatic notification and warning before and after delete (no crazy templates)
 * Report - e.g non-rendering image, invalid html markup showing on page, and copy-editing issues, problem loading page. Sometimes the user can just fix it, but many times the problem might be so complex (think deeply nested transclusions)
 * File maintenance - Flagging file as innappropriate, as requiring copyright (might need structured data), as containing useless description or file name
 * Discussion based tickets - flagging inappropriate posts, flagging spam, flagging vandalism, flagging harassment
 * Be extensible for future needs
 * A clear central area to manage there reports and act upon them.

A good number of actions don't really require any edits to pages at all, especially not to add templates. These maintenance type templates were always a hack created to account for the fact that mediawiki lacks any tool or extension to do so. A javascript based gadget / script is something that could add some of these functionalities, but the lack of a central database to store the queue makes it a horrible hack.

P.S. If well defined, this might actually be a good candidate for GSOC, so it might be worth turning this into a ticket rather than a lost RFC here.197.218.91.29 19:39, 11 March 2017 (UTC)