Page MenuHomePhabricator

Cleaning up #Mediawiki-extensions-other
Open, Needs TriagePublic

Description

MediaWiki-extensions-Other has long been known as a place where tasks usually go to rot.

This is a proposal to clean up the tag by creating individual projects for all extensions that have a current open task in in -other.

This will involve the creation of approx 106 projects based on some information i gathered the other weekend (P7946)

What about tasks where there is a upstream task tracker?
There is a about 9 projects out of that list where I identified a upstream task tracker, My idea would be to still create create the project and move the tasks but also archive the project and add a clear link in the description on where the upstream tracker can be found for future reference.

What about tasks where there is a extension is archived?
Create and archive the project, and decline any tasks. Although I didn't find any when going through the list.

Notifying extension authors
Leaving a talk page message for the authors to watch the relevant projects.

Future work
Progressively monitor new tasks over time and create projects as required.

Who?
I'm happy to do it.

Related Objects

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 16 2019, 12:35 AM

I agree that it doesn't really matter if tasks are filed as long as there is not separate project for them, as noone will ever find them anyway. However, if noone is active at maintaining a project, I don't know if this will really solve the issue.

I understand the reasoning behind this but I am skeptical about how good an idea it is to create phab projects for code that might not actually be tracking issues in Wikimedia Phabricator.

As long as the source code is hosted in Wikimedia Gerrit, I think we should have Phabricator projects for tracking purposes. If we have open tasks and no maintainers, then we should consider archiving the source repositories.

I think the ability to properly track and categorize stuff would be helpful, and given that no one is looking at the -other project now, splitting it into more projects doesn't seem like it would hurt.

Thanks for filing this.

Leaving a talk page message for the authors to watch the relevant projects.

This needs to happen before creating a project tag, and getting consent and agreement from the developer/maintainer that they want to use Wikimedia Phabricator for tracking tasks and especially that there is not already an issue tracker somewhere else. I do not want to create a place in Wikimedia Phabricator where people file tasks while the maintainer/developer of a codebase expects those tasks to be filed somewhere totally else.

Thanks for filing this.

Leaving a talk page message for the authors to watch the relevant projects.

This needs to happen before creating a project tag, and getting consent and agreement from the developer/maintainer that they want to use Wikimedia Phabricator for tracking tasks and especially that there is not already an issue tracker somewhere else. I do not want to create a place in Wikimedia Phabricator where people file tasks while the maintainer/developer of a codebase expects those tasks to be filed somewhere totally else.

I think we should weaken this requirement in this special case, as it's unrelaistic to get confirmation from hundreds of users. Maybe the Archival proposal from @Peachey88 is the right way to go here.

It might be unrealistic but then I might miss the point of the entire proposal? :)
Which underlying problem is solved by spending time categorizing things if noone plans to take care about the items in the categories?

Maybe we should archive MediaWiki-extensions-Other first, then create projects for extensions on an as-needed basis.

Maybe we should archive MediaWiki-extensions-Other first, then create projects for extensions on an as-needed basis.

We would have no active projects for some extension tasks for some time if we do this. The nice thing about MediaWiki-extensions-Other is that you can split extensions out of it one by one, and archive it after you are done.

I understand the reasoning behind this but I am skeptical about how good an idea it is to create phab projects for code that might not actually be tracking issues in Wikimedia Phabricator.

There is only a small subset that actively document that are tracking their issues elsewhere, and if we find that they are using a tracker elsewhere, we can easily archive the project and add a note to where tasks should be filed

As long as the source code is hosted in Wikimedia Gerrit, I think we should have Phabricator projects for tracking purposes. If we have open tasks and no maintainers, then we should consider archiving the source repositories.
I think the ability to properly track and categorize stuff would be helpful, and given that no one is looking at the -other project now, splitting it into more projects doesn't seem like it would hurt.

Indeed, and that is why a lot of the extensions were created in BZ, because we host their code so its naturally people will submit to our tracker, and projects in phab are cheap!

Maybe we should archive MediaWiki-extensions-Other first, then create projects for extensions on an as-needed basis.

I think its still worth while keeping the -other project active as a triage point.

It might be unrealistic but then I might miss the point of the entire proposal? :)
Which underlying problem is solved by spending time categorizing things if noone plans to take care about the items in the categories?

I find them valuable as a person filing bugs for all the misc/random extensions. For example, when we adjust CI configuration, I'll find repos failing tests, and so I need to file a task. And then I need to search for the project, not find it, then look in -other, try to see if anyone else might have filed it before, and then file a task. Giving each repository its own project would make that process much easier. It would help with developing tooling that looks at bugs per repository as well.

And yes, it's possible that no one is paying attention to the project, but that's fine, since at least the issue is recorded in an issue tracker, and easily searchable by other people.

I think there are other side benefits as well, like making it easier to spot problematic, unmaintained extensions (no subscribers/watchers with bugs piling up).

There is only a small subset that actively document that are tracking their issues elsewhere, and if we find that they are using a tracker elsewhere, we can easily archive the project and add a note to where tasks should be filed

I'd prefer to not create such projects in the first place instead.

Went through the open tasks. Duplicator and DocBookExport seem to have a bunch of open tasks so I think that would pass my imaginary threshold to create dedicated project tags. For the rest I remain reluctant until there is commitment by maintainers to look into Wikimedia Phabricator...

Liuxinyu970226 added a comment.EditedFeb 3 2019, 1:08 PM

Other-skins is likely or not?


Anyway for Notifying extension authors, I would suggest:
Just try to search their usernames or real names within Phabricator, and just add them to the associated projects if existing, and for those who're not registered Phabricator, send e-mails to them, to let them register.

Isarra added a subscriber: Isarra.Apr 5 2019, 12:37 AM

Well, I just totally failed to find at least one LogoFunctions task I was specifically looking for in there because all I found was a different one, and filed a duplicate...

I'd say if they've got more than two or three tasks, it might be time to consider it.

Anyway, that was annoying, so now we've made a project for that one, at any rate. >.>

Went through the open tasks. Duplicator and DocBookExport seem to have a bunch of open tasks so I think that would pass my imaginary threshold to create dedicated project tags. For the rest I remain reluctant until there is commitment by maintainers to look into Wikimedia Phabricator...

I don't think that spending time on creating project tags for the rest makes sense. See the first three comments on this task.

I propose to decline this task. If specific projects are wanted && an active maintainer agrees, please request / create Phabricator project tags.

In my opinion every repository in Gerrit should have its own Phabricator project. User stories:

  • As a sysadmin who is looking to use a new extension, I'd like to clearly be able to see all the filed bugs/feature requests for the extension, before I decide to enable it.
  • As a budding developer who just fixed an easy bug in an unmaintained extension, I'd like to fix other bugs as I'm getting more familiar with the code base. This is easiest to find when they're all in their own Phabricator project.
  • As a now more experienced developer who is feeling comfortable with an extension, I'd like to automatically subscribe to new bugs filed for that extension. This is easiest to do when they're all already in their own Phabricator project, otherwise I'd have to ask someone to create it for me, which is unnecessary friction.

I can write some more if that exercise would be useful. Ultimately, I see significant value in categorizing tasks, even despite not having an active maintainer to deal with them.

In the few cases where there's some alternative task tracker, we can deal with those specially, but that shouldn't hold us up from creating the overwhelming majority of projects.

I agree with @Legoktm here. Actually finding relevant issues without a specific project is much harder. Furthermore, this provides us with a generic, unified workflow when considering extension issues, which I think is quite nice.