Page MenuHomePhabricator

Using Phabricator for gadget-related tasks
Closed, ResolvedPublic

Description

Currently, issues related to gadgets are typically tracked on some wiki, resulting in various degrees of awkwardness (hard to search old issues, especially if one is not sure which wiki "owns" the gadget; hard to cross-reference tasks; hard to watch/get updates; no easy way to claim or prioritize; etc).

I wonder if tracking these (or some of these) on Phabricator would make sense? Thanks to OAuth, Phabricator is quite accessible to Wikimedians; but all Phabricator content is currently in English which might be problematic (there are lots of gadgets which are only used by some single non-English language community; forcing them to discuss in English seems counterproductive).

See also

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Aklapper added a comment.EditedApr 9 2015, 9:25 PM

I might repeat myself, but before T1238 is getting close to getting solved I oppose handling on-wiki code bugs/requests in Wikimedia Phabricator.
I don't plan to spend more of my triage time trying to track down gadget differences between wikis due to copying random code and cargo-cult programming, or which gadget loaded from which other gadget code could have created which exact problem after disabling each gadget one by one. These are fundamental problems to resolve first.
While providing an issue tracker for well-defined projects for interested gadget maintainers is a clear plus, the increased level of entropy in which places to track which problems (and actually understanding that!) is a big enough minus. I face that confusion already for tools on Tool Labs and I do not need more of it.
What I wrote above in my previous comment is still valid.

gpaumier added a subscriber: gpaumier.

Putting back in the queue until there's more consensus here.

Qgil added a comment.Apr 9 2015, 10:21 PM

OK, I have been convinced by @Aklapper. :)

gpaumier moved this task from Triaged to Archive on the Notice board.Apr 16 2015, 5:18 PM

Personally I don't think the code repository should affect whether the application or gadget uses Phabricator to track its tasks, they are somewhat tangentially related, but not so related that they are bound. It shouldn't matter if the projects uses Sourceforge, Github or keeps the code on the Wiki.

A couple notes about using Phabricator to track gadget changes.

*Autowikibrowser, although not a gadget, just migrated all their bugs and Feature requests to Phabricator but they currently use Sourceforge for the code. They are talking about moving it, but that hasn't happened yet.
*Many to most of the Gadget keepers do use Phabricator and in the case of some, including Twinkle I think, they work for the WMF.
*I do think that gadgets need to be identified as such in the project name (maybe something like Twinkle-Gadget).
*Personally I think relevant changes to the applications, including the gadgets should be tracked in Phabricator as a general requirement. Possibly even some of the larger and more active bots.

So I'm not going to push the issue, but I do really think that most to all of the major gadgets like Twinkle and the New pages patrolling tool, the Crop tool on commons and the like should be tracked regardless of where they choose to store the code.

Qgil added a comment.Jun 16 2015, 9:16 PM

A couple months later... :)

I don't plan to spend more of my triage time trying to

But that's fine. If we agree that these gadget related projects can be created only by their maintainers, and we agree on a nomenclature like #Foo-Gadget, you and anybody else not willing to put too much attention on gadget projects in Phabricator before T1238 can just ignore them. I think gadget maintainers caring about their gadgets deserve a chance to prove their responsibility.

While I agree that there is a risk that low quality gadgets with low quality distributions and "low quality" bugs have a risk of contaminating Pahbricator with such load of low quality... I believe it is worth opening the door to gadget projects and maintainers, so they can benefit from the good standards that we are trying to pursue in Phabricator and surroundings. A task manager does help managing tasks better than wiki pages, so in a way we will be helping those who care improving the quality and development process of their gadgets.

PS: I'm thinking all this also in the context of T97273: Simpler process for Phabricator project creation.

Personally I don't think the code repository should affect whether the application or gadget uses Phabricator to track its tasks, they are somewhat tangentially related, but not so related that they are bound. It shouldn't matter if the projects uses Sourceforge, Github or keeps the code on the Wiki.

As AWB was mentioned, AWB has one central codebase as far as I know, in a code revision control system (Git, SVN).
For gadgets being code in wiki pages, in the best case the "original" code is embedded via importScript(), in worst cases code is being copied around between sites and unfortunately not always kept up-to-date or understood.
Taking a random example like Twinkle (cf. T102657), I'd say there's not that single "Twinkle" gadget: I look at https://en.wikipedia.org/wiki/MediaWiki:Gadget-Twinkle.js and https://hi.wikipedia.org/wiki/मीडियाविकि:Gadget-Twinkle.js and https://outreach.wikimedia.org/wiki/MediaWiki:Gadget-Twinkle.js and I see pretty different code versions.

I have spent time trying to help debugging gadget issues in the past that resulted from copying gadget code, not maintaining it by not syncing it and by ignoring deprecation warnings, and once things finally broke, a task was created. That adds to my reluctance.

But even more important: There would be another feedback place added to the mix, beside on-wiki talk pages for gadgets or (taking Twinkle as an example) other places like GitHub where bugs are already tracked, potentially creating even more divide in communication. One intention to introduce Phabricator was to have less of a divide.
Adding one more place to create bug reports won't decrease that divide.

If somebody worked on a clear plan to decrease that divide I'd be way less reluctant. Would you be willing?

Qgil added a comment.Jun 17 2015, 12:23 PM

For what is worth, in my comments above I have been assuming that when the maintainers of a gadget request a Phabricator project for it, they will direct the other feedback channels here. Assuming is not good, so I would be happy setting this as an explicit rule of this game.

Aklapper added a comment.EditedJun 17 2015, 12:47 PM

I have been assuming that when the maintainers of a gadget request a Phabricator project for it, they will direct the other feedback channels here

Ah. :) Yes, would like to be as explicit as possible here.
Probably by creating a dedicated "On-wiki Gadgets" subpage linked from mw:Phab/Creating and renaming projects#New projects.

I would like us to clearly communicate to gadget maintainers that

  • only gadget maintainers themselves can request a Phab project for their gadget,
  • just throwing a Phab project for a gadget over the wall might not make task and bug management easier but actually harder due to adding one more feedback place to the mix. Maintainers need to have thought about already-existing places (talk pages, copying gadget code around, other places like GitHub)

and I would like us to ask maintainers who request a Phab project for their gadget

  • where they currently receive or maintain bug reports and enhancement requests
  • if they are committed to and feel responsible for (re)directing bug reports and enhancements to the right place (Phabricator), especially in addition and contrast to requests like "I copied your gadget code to my wiki and it doesn't work there" or "We copied your gadget code a while ago to xyz.wikipedia.org and now it suddenly broke; please fix!".

I know I need better phrasing for all this but I guess you get me.

I do agree that the maintainers of the Gadget should request and Manage the Phab project for it but it should at least be allowed.

I do also agree that not every script necessarily needs to be accounted for but IMO the main stream ones like Twinkle, New Pages patrol and the ones listed under the gadgets tab under preferences should be.

As for the question of would I be willing to help draft a clear plan, yes I would and could start working on that. If the WMF has a certain format they prefer please let me know.

Reguyla added a comment.EditedJun 17 2015, 3:05 PM

Also, for what its worth I think this needs to be updated since the migration has mostly been completed. Also, from reading that the idea of using Phabricator to track the tools and scripts seem to be supported in the documentation to minimize and consolidate the multiple locations being used into one.

With that said, I do not think that we will ever nor should we try, to get completely away from bugs and features being brought up on Wiki. Someone will still need to migrate them here, but there is a lot of value to discussing some of the issues on Wiki first to reduce creating task requests for stuff that cannot or will not be done.

I do agree that the maintainers of the Gadget should request and Manage the Phab project for it but it should at least be allowed.

Please provide reasons if possible. (I've seen project creation requests by non-maintainers. So maintainers don't even know that there's yet another place to look at where bug reports about their project might end up being ignored and forgotten due to missing awareness. All with best intentions of non-maintainers, of course.)

I do also agree that not every script necessarily needs to be accounted for but IMO the main stream ones like Twinkle, New Pages patrol and the ones listed under the gadgets tab under preferences should be.

See my concerns above - replies to those specific concerns are very welcome. :)

As for the question of would I be willing to help draft a clear plan, yes I would and could start working on that. If the WMF has a certain format they prefer please let me know.

I think Quim's comments above helped already so I'd stick to T85433#1373799.
Still a bit unclear to me how to "identify" maintainers actually, and my interpretation that there is no single version of a gadget - would a project cover all versions across all sites? And a small sidenote: I'm not sure why WMF was mentioned in a previous comment, as they are pretty unrelated to this problem and discussion I'd say. :)

[offtopic]

Also, for what its worth I think this needs to be updated

You are very welcome to just update it, or to bring up your thoughts on the related discussion page (as I cannot see any outdated information on that page currently). In any case, thanks a lot for your help to keep the wiki content updated! :)

Ok, I wasn't sure if I was allowed to update that.

My comment about the WMF was simply that if they had a certain format or procedure they like to stick to when developing project plans that would be good to know in advance before we start plodding along and find out we haven't filled out the proper cover page on the new TPS report. :-)

Maybe I am just making a mountain out of a mole here in regards to using Phabricator to track bugs with applications like Twinkle but maybe I will ask a couple what they think before I start working on "a plan forward". I'm not going to pester too many, but I'll ask a couple of the more active ones for the larger items just to see if there is any interest. If not then there is no need to even pursue the issue IMO.

He7d3r added a subscriber: He7d3r.
He7d3r updated the task description. (Show Details)Jul 16 2015, 10:08 PM
He7d3r updated the task description. (Show Details)Jul 16 2015, 10:29 PM

Personally, I think using Phabricator for gadget-related tasks is great. I would not encourage every gadget under the sun to set up a Phabricator project though, just ones that actually need it (i.e. the large complicated ones).

Qgil awarded a token.Aug 14 2015, 7:41 PM
Aklapper added a comment.EditedAug 18 2015, 5:33 PM

Just to clarify my position, seeing the Community-Tech team tracking some gadget issues in Phabricator in T108282:
If a defined team explicitly feels responsible for specific gadget related tasks I'm fine with the CT team creating such tasks for themselves, or the CT team explicitly asking community members to file gadget related tasks and associating Community-Tech as the project of such tasks. There is already a precedent for tracking gadgets on a specific site that a team feels responsible for in T100512: Create a "Wikidata-Gadgets" project.

In general and as explained above, I would simply like to avoid fragmentation: Phabricator where some of the gadget-interested community discusses, while the others discuss on-wiki. Getting the stakeholders and interested gadget folks together in a single place needs communication. Hence my reluctance.
So I'd still be against a generic #Wikipedia-Gadgets project for everybody filling their on-wiki gadget issues (with expectations on getting support or even expecting others to fix them) without a communication plan laid out before.

Wikimedia-General-or-Unknown has always been the designated component for such issues; it's unclear to me how creating a specific component would help the issues find a fixer/fix.

Phabricator is a last resort for such reports and has many drawbacks compared to on-wiki reporting (like awful search, English dominance, poor wiki features, negligible fraction of users registered), I don't see why we would actively encourage people to use it when they are more comfortable elsewhere; it's perfectly fine when they use it out of personal choice.

Qgil added a comment.Aug 27 2015, 8:14 AM

T85433#1373799 still stands, then? We are not pushing any changes to gadget maintainers and their users, but we allow the creation of projects for gadgets when requested by their maintainers, knowing the implications. Such implications could be documented in a specific section at https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects

T85433#1373799 still stands, then? We are not pushing any changes to gadget maintainers and their users, but we allow the creation of projects for gadgets when requested by their maintainers, knowing the implications.

Yes. https://phabricator.wikimedia.org/tag/formwizard/ is another example.

Such implications could be documented in a specific section at https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects

Still TODO but very good point.

Will meta admins be watching those projects for tasks to take on? Or, now that you've decided that Phabricator is open for such requests, are we going to have to come and nag you to deal with each of your wiki's users who expects us (developers) to mess with your wiki's gadgets, instead of sending them to you?

Respectfully, this comment conveys an attitude that there's an "us" (developers) and a them (gadget authors). I agree with @Tgr (T85433#1194689) that this is not really a helpful distinction.

This comment also conveys an ownership attitude over all of Phabricator. Phabricator and any system like it, including MediaWiki, are built to scale in such a way that even if there are millions of items, they shouldn't be getting in your way most of the time. That is, as many have noted here already, we use Phabricator with many projects and people generally have little issue ignoring or following the projects and tasks that they're interested in.

I agree with @Nemo_bis that we should leave the decision of where to file an issue to personal choice. A gadget talk page might be the best venue, but using Phabricator Maniphest is certainly not wrong for reporting technical issues on Wikimedia wikis, in my opinion.

If these tasks really bother people so badly, moving the discussion is acceptable. But that requires actually moving the discussion, not just closing the task as invalid and telling the user to go away. Copy and paste the issue description and any discussion to a different location (such as a wiki talk page) and provide a pointer link. Treat others as you would want to be treated. Otherwise, just don't follow that task and leave it be?

Will meta admins be watching those projects for tasks to take on? Or, now that you've decided that Phabricator is open for such requests, are we going to have to come and nag you to deal with each of your wiki's users who expects us (developers) to mess with your wiki's gadgets, instead of sending them to you?

Respectfully, this comment conveys an attitude that there's an "us" (developers) and a them (gadget authors). I agree with @Tgr (T85433#1194689) that this is not really a helpful distinction.

They are two separate groups and I identify mainly as a developer. I do a little bit of gadget maintenance every once in a while but I am primarily a developer. The distinction exists, at least in my mind.

This comment also conveys an ownership attitude over all of Phabricator.

I don't know whether you're claiming that I have some sort of ownership attitude over Phabricator (which I don't, btw, I am attempting to participate in a community discussion with my opinion - I'm not going to run around and lock everything down if it turns out everyone else disagrees with me), or whether you think I'm suggesting that the developers have ownership of Phabricator, or something else, but I'll try to address this anyway.

Gadget developers should feel, as far as I am concerned, very welcome (encouraged, really) to come to Phabricator, request a project, and instruct their users to file bugs against their software in that project. I'm only trying to deal with tasks that do not fit into any clearly defined component/maintainer.

Phabricator and any system like it, including MediaWiki, are built to scale in such a way that even if there are millions of items, they shouldn't be getting in your way most of the time. That is, as many have noted here already, we use Phabricator with many projects and people generally have little issue ignoring or following the projects and tasks that they're interested in.

The *number* of tickets existing without fitting in anywhere clearly is not the issue, it's tracking them in a useful manner. Many users have the expectation that when they file tasks here, someone is keeping an eye out for tasks like theirs to work on. This is usually done by developers looking at specific projects. Wikimedia-General-or-Unknown needs to go. Have you read my essay on this subject? As you can tell, I have trouble communicating the exact problem I see here.

I agree with @Nemo_bis that we should leave the decision of where to file an issue to personal choice.

And let Phabricator/Maniphest have scope limited only in that tasks have to be vaguely Wikimedia-related? No thanks. This instance is not limited to technical tasks, but I hope we don't start seeing people report issues with (for example) wikipedia article content here. Why? The reason most relevant to this discussion is that the relevant editors are not looking for issues here.

A gadget talk page might be the best venue, but using Phabricator Maniphest is certainly not wrong for reporting technical issues on Wikimedia wikis, in my opinion.

Right now, not all gadgets used on Wikimedia wikis have projects here. And with the current system you can't force all gadget developers to track their tasks here. We should be pointing users towards the best venue.

Treat others as you would want to be treated.

If I were a user, I'd find what I am saying to be very helpful. I am not mistreating users by watching new tasks without projects for scope issues and redirecting some. I wouldn't want to waste time hoping that someone with all the correct knowledge and permissions will find my task somewhere in the depths of Phabricator (either with no projects or worse - in the depths of Wikimedia-General-or-Unknown), when I can go to the relevant wiki admins/gadget developers instead.

Tgr added a comment.Mar 9 2016, 9:23 PM

I think we all agree on the principles (if maybe not on how to prioritize them):

  1. If a Wikimedia- or MediaWiki-related group is in need for a task management platform and want to use Phabricator, we should welcome them.
  2. If a group has chosen to use something else, we should not accept tasks related to that group.
  3. It should not be too hard for users to figure out where to file tasks.

So if the gadget maintainer prefers talk pages, Phabricator should not accept tasks for that gadget. If the maintainer is interested in using Phabricator, it should, as long as that does not make the situation for bug reporters more confusing. That could be handled by having a wiki page listing all gadgets and where bug reports should go. (Ideally the gadget itself should include a bug report link, on Special:Preferences or its UI or its description page which is linked from the previous two.)

Elitre added a subscriber: Elitre.Mar 18 2016, 2:04 PM

Ideally the gadget itself should include a bug report link

Do we have reason to believe this doesn't usually happen?

Aklapper added a blocking task: T121470

I don't get this one.

Aklapper added a blocking task: T121470

I don't get this one.

See T85433#1196089, T85433#1373671, T85433#1373799

I don't get this one.

See T85433#1196089, T85433#1373671, T85433#1373799

It seems that you oppose encouraging/forcing people to move to Phabricator, as that would produce more work without benefits. On this I agree.

"Using Phabricator for gadget-related tasks" however describes something that is already happening and is not blocked on any future event. I guess we should change the subject to "Encourage/force greater use of Phabricator for gadget-related tasks" and close it declined (it's not really wanted) or invalid (not really under anyone's control).

Aklapper updated the task description. (Show Details)Oct 14 2016, 3:08 PM

For the records, I've given @Sophivorus rights to create a project for the ProveIt gadget as requested. @Sophivorus is aware of this very task and T121470: Central Global Repository for Templates, Lua modules, and Gadgets and we're happy to iterate/improve.

Nemo_bis closed this task as Resolved.May 29 2017, 10:08 AM
Nemo_bis claimed this task.
In T85433#2104699, @Tgr wrote:

I think we all agree on the principles (if maybe not on how to prioritize them):

  1. If a Wikimedia- or MediaWiki-related group is in need for a task management platform and want to use Phabricator, we should welcome them.
  2. If a group has chosen to use something else, we should not accept tasks related to that group.
  3. It should not be too hard for users to figure out where to file tasks.

I agree we agree on this. :-) I've now expanded the Wikimedia-General-or-Unknown description to clarify what can be done or is normally done on Phabricator (basically just added examples and links; the

Nemo, I think your comment above is cut.

Nemo, I think your comment above is cut.

It is. Which confuses me: how this task should be announced in Tech News?

@Trizek-WMF: No idea, not even convinced it is a good idea / worth to mention. That User-notice tag was added more than two years ago, see the history of this task...

Johan added a subscriber: Johan.Jul 20 2017, 2:54 PM

@Trizek-WMF: No idea, not even convinced it is a good idea / worth to mention. That User-notice tag was added more than two years ago, see the history of this task...

Agree.

Elitre updated the task description. (Show Details)Jul 21 2017, 6:53 AM
Trizek-WMF removed a subscriber: Trizek-WMF.