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.

In T213880#4883219, @Aklapper wrote:

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.

In T213880#4883399, @mmodell wrote:

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.

In T213880#4883183, @Krenair wrote:

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

In T213880#4883198, @Legoktm wrote:

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!

In T213880#4883399, @mmodell wrote:

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.

In T213880#4883251, @Aklapper wrote:

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).

In T213880#4887077, @Peachey88 wrote:

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...

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.

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. >.>

In T213880#4909617, @Aklapper wrote:

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...

• created MediaWiki-extensions-DocBookExport, updated its extension homepage, and tagged existing tasks.
• MediaWiki-extensions-Duplicator already got created by Cindy in March 2019.
• created MediaWiki-extensions-GoogleAdSense, updated its extension homepage, and tagged existing tasks

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.

If someone works on this, please make sure that

• any potential newly created Phabricator project has a proper one sentence project description (I usually copy the sentence from the extension homepage on mediawiki.org), and a link to the homepage like ([Homepage](https://www.mediawiki.org/wiki/Extension:Example)),
• projects in Phab must not duplicate already existing issue trackers (e.g. something on Github, check the extension homepage before for any link!)
• a corresponding Phab project tag is linked from the homepage infobox on mediawiki.org (via the bugzilla or phabricator parameter),
• maintainers (if existing and if feasible) are aware of a Phab tag created for their project.

I'm proposing to close this task, as I am not aware of any clear criteria when to define this task as "resolved" and as tasks should not be neverending.

This task would be done when every extension has its own project and MediaWiki-extensions-Other is archived.