Open MusikAnimal opened 5 years ago
I'm happy to take it on
Go for it! I'll gladly review.
Are you imagining this living in the csd module, prod, or something new/separate? It's a bit of a departure from most of Twinkle, but it seems like something that'd help (reviewing) NPP work, and anything we can do to help them is probably worth it.
Go for it! I'll gladly review.
Thanks :)
Are you imagining this living in the csd module, prod, or something new/separate? It's a bit of a departure from most of Twinkle, but it seems like something that'd help (reviewing) NPP work, and anything we can do to help them is probably worth it.
Yes I was thinking the speedy module, where it currently handles the logging. We'd register the hook (action callback, technically is I guess is what it's called) somewhere towards the bottom, with clear comments as to why it's there. The NPP community wanted Page Curation to go off of twinkleoption.js, too, so it was obvious that Twinkle should be doing the work. I'm glad to hear approval :) Twinkle.speedy.callbacks.user.addToLog
should work nicely. We might need to adjust some code to have it return a promise, but that shouldn't be too hard either.
Let's see what it looks like. While I certainly prefer Twinkle usage, it's not a competition. In general, I think it's better not to insert Twinkle to places outside of Twinkle, but the alternative here is having all NPPers load in a new, separate gadget or userscript, whereas they already have Twinkle installed. In this regard, the existence of CSD/PROD logs is a Twinkle invention, so it does make some sense to ensure we're the "owners" of those pages/preferences. At any rate, let's see what it looks like.
Yes, I totally understand where you're coming from @siddharthvp, but I also don't think we need to worry too much about Twinkle losing market share :) It's well-understood that Page Curation is geared specifically toward new pages, and offers some features that Twinkle is unable to (Special:NewPagesFeed and associated metadata in the curation toolbar), and Twinkle meanwhile is a general purpose Swiss army knife that no one is going to uninstall. They wanted to go off of twinkleoptions.js, after all, so that secures Twinkle as a prerequisite.
The bottom line is relying on a gadget from within MediaWiki isn't really an option. The community really wanted the CSD/PROD logging. Allowing Twinkle to integrate with Page Curation seemed like the best compromise, rather than trying to reinvent the wheel and create a maintenance burden, which as you correctly say won't scale once development stalls.
The action queue functionality has been deployed so I will get a start on this soon. Thanks!
@MusikAnimal It's just that I have never understood why PC's tagging and deletion modules exist. Those who request features for it, as well those who work on it, both seem to be trying to make it "on par with Twinkle" (that being a commonly used phrase, re WP:PCSI). Heck, why not just ask people to use Twinkle instead, and restrict PC to its newpagesfeed/metadata/wikilove etc modules? IMHO, lots of paid developer time that could have been better utilized in building software that doesn't duplicate existing ones.
I cannot get into the politics. I don't know why these decisions were made back in 2011. Community Tech merely did what the community asked for in the wishlist survey. There was careful attention to staying within scope, and nothing new has been built that replicates Twinkle (hence why this issue was created). I recommend consulting the NPP community directly regarding long-term plans or making major changes to their workflow. For now I hope we can live with this compromise to add CSD/PROD logging, and that both tools can coexist peacefully. Thanks for your understanding!
@MusikAnimal Do you have any interest in taking this on? I know this is still one of the top requests from NPP and it seems like this is the path that gets us to a solution quickest (versus doing this in PageTriage).
@MusikAnimal Do you have any interest in taking this on? I know this is still one of the top requests from NPP and it seems like this is the path that gets us to a solution quickest (versus doing this in PageTriage).
I don't think I have time right now, unfortunately. I haven't touched Twinkle in ages.
For anyone interested, docs on integrating with PageTriage are at https://www.mediawiki.org/wiki/Extension:PageTriage#Client-side_hooks
See https://phabricator.wikimedia.org/T230455 for context.
Page Curation is a MediaWiki tool to help with new page patrolling, and offers some functionality similar to Twinkle. Users of the extension have requested that speedy/PROD nominations from Page Curation be logged to Special:MyPage/CSD_log, etc., just as Twinkle does. This was investigated and decided that this is solely a Twinkle invention, and especially given the changes to the logic over the years, it is better handled by Twinkle itself rather than MediaWiki.
https://gerrit.wikimedia.org/r/530977 introduces an "action queue" (similar to mw.hook) that allows integration with Page Curation. The difference from mw.hook being that the action queue is promised-based, which is necessary since Page Curation wants to reload the page after tagging. The proposal is for Twinkle to listen to the
delete
event and log the nominations just as Twinkle's speedy module does.I don't think this will be a lot of work, and it'd really help out the NPP community. I'm happy to take it on, if no one is up for it, but I'd like to get the go ahead from you all.
The action queue functionality goes live next Thursday, September 26. Documentation for action queue is at https://www.mediawiki.org/wiki/Extension:PageTriage#Client-side_hooks