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)