I commented there.

Distilling my comments from T85433 that apply to Twinkle and turning them into discussion points here:

• What will happen to existing bug trackers for Twinkle, such as on GitHub?
• How would users on Twinkle talk pages get informed about the Phabricator project and that they'd be supposed to report bugs in Phabricator (or how are users currently informed to report Twinkle bugs on Github, if they are supposed to do so, or are Twinkle maintainers subscribed to those talk pages and take useful comments and turn them into bug reports themselves)?
• What's the idea for the "Twinkle" gadgets with different code on different sites, like en.wp, hi.wp or outreach.wm (list not complete)? Would all these instances be covered by such a Phabricator project, and what would reporters be told when they filed a bug in Phab about code that is not "the latest code"? "Please use importScript() and stop copying code over?" :)

All good questions and they deserve an answer.

• If the developers want to use Phabricator I would assume that the bugs on GitHub would be imported as were the bugs from Bugzilla. Or they could simply start from that point on. I cannot answer that its up to the developers.
• The second question isn't really anything we should worry about IMO. How are the users notified now of other problems? With Commons, with AWB or the dozens of other projects tracked on here. I don't think we should force anyone to use Phabricator and some discussions on the projects talk pages should not be here. So I don't think the Wiki pages would ever go away.
• As for the code I think it should be handled as we are doing with AWB and other apps. If there is a need to track it by project then they can create a column, otherwise it just gets lumped into the Bugs/Feature requests and the developers can work on them as they choose. Additionally, having them all in one place potentially would be a huge benefit rather than having the bugs scattered across a couple dozen projects.

I agree there are problems with copying code and not knowing how it works well enough to fix it when it breaks. All I am suggesting in all of this is that if the developers want to use Phabricator I think they should have that option rather than just be told nope! You are not one of the chosen. I think some will and many won't.

Currently there is no way to track the bugs for Twinkle and they are all done on Wiki.

So that initial statement (and underlying assumption) in the task description might be incorrect, as https://github.com/azatoth/twinkle/issues exists?

And I would like to stress again that I oppose project creation requests that do not come from the project's maintainers, for reasons given in T85433.

I actually agree with you on the point of the developers should request themselves and not be done by well meaning requesters like myself. I hadn't really considered that when I submitted the request to be honest but it makes complete sense.

I don't have a problem with closing this but I recommend prior to doing that we ping the developer and give them a chance to respond to see if they are interested in using the tool. If not then we should just close it and carry on.

@Azathoth, is this something you are interested in? Or should we just go ahead and close this.

Very much in favour of this. With the block module I'm regularly triaging requests, and using software intended for this kind of stuff very much makes sense to me =P

It's a difficult question. As for me, I'm quite happy using GitHub and WT:TW for now. Although few people choose to create a GitHub account simply to report a bug, it's not as if the volume of bugs and requests is that great, and we can handle it well at WT:TW. So it would be a "no" from me.

Yes, and I should clarify that I'm getting a good number of requests simply because Block module is new and we're still ironing out all the issues. So it's true that dealing with the requests will become less of a problem in the long run.