Add-on maintainers list #84471

New Issue

Mikhail Rachinskiy · 2021-01-06T21:33:18+01:00

2021-01-06 21:33:18 +01:00

Currently there is no way to know who are add-on maintainers, unless you heard it from the maintainer himself or looked at commit history. This is an issue for triaging bug reports and patches for review.

Add-on meta information does not help, since add-on author is not always an active maintainer, for example Bool Tool has five authors, but only one maintainer. glTF has seven authors, and looking at commit history it seems like it has only one maintainer too.
Also it should not be required to look at the source code to decide who needs to be assigned to a task.

I think add-on maintainers list, similar to module owners and translators would be an adequate solution, but maybe you have a better idea?

Currently there is no way to know who are add-on maintainers, unless you heard it from the maintainer himself or looked at commit history. This is an issue for triaging bug reports and patches for review. Add-on meta information does not help, since add-on author is not always an active maintainer, for example Bool Tool has five authors, but only one maintainer. glTF has seven authors, and looking at commit history it seems like it has only one maintainer too. Also it should not be required to look at the source code to decide who needs to be assigned to a task. I think add-on maintainers list, similar to module owners and translators would be an adequate solution, but maybe you have a better idea?

Mikhail Rachinskiy commented

2021-01-06 21:33:18 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Mikhail Rachinskiy commented

2021-01-06 21:33:18 +01:00

Added subscribers: @MikhailRachinskiy, @ideasman42, @dfelinto, @mont29

Bastien Montagne commented

2021-01-07 11:19:51 +01:00

Personally I would add a way to tell who is current maintainer of an add-on in its meta data:

Simplest would be to have the convention that the first author listed is the current (main) maintainer?
We could also add some kind of textual tag next to a name (like - [x] or so).
Finally, we could add an new field to those meta-data for maintainers?

bottom line being, I'd rather see this put in add-on code itself with all its other meta-data, than in yet another external list that would go out of sync very quickly imho?

Personally I would add a way to tell who is current maintainer of an add-on in its meta data: * Simplest would be to have the convention that the first author listed is the current (main) maintainer? * We could also add some kind of textual tag next to a name (like `- [x]` or so). * Finally, we could add an new field to those meta-data for maintainers? bottom line being, I'd rather see this put in add-on code itself with all its other meta-data, than in yet another external list that would go out of sync very quickly imho?

Mikhail Rachinskiy commented

2021-01-07 14:00:11 +01:00

Simplest would be to have the convention that the first author listed is the current (main) maintainer?

There would be no way to tell authors and maintainers apart, if add-on has more than one maintainer.

We could also add some kind of textual tag next to a name (like - or so).

Finally, we could add an new field to those meta-data for maintainers?

That would be better than nothing, still it requires triager to scan the sources.

As I understand it, it is strictly a management issue at developer.blender.org platform, and therefore it should be resolved at the platform level, not the add-on source code level.

> - Simplest would be to have the convention that the first author listed is the current (main) maintainer? There would be no way to tell authors and maintainers apart, if add-on has more than one maintainer. > - We could also add some kind of textual tag next to a name (like - [x] or so). > - Finally, we could add an new field to those meta-data for maintainers? That would be better than nothing, still it requires triager to scan the sources. As I understand it, it is strictly a management issue at `developer.blender.org` platform, and therefore it should be resolved at the platform level, not the add-on source code level.

Mikhail Rachinskiy commented

2021-01-07 14:13:21 +01:00

Finally, we could add an new field to those meta-data for maintainers?

This could be useful if maintainers put in their developer.blender.org ids, then we could make use of add-on's Report a Bug operator and automatically assign maintainers to reported bugs.

But then does anyone actually uses add-on's Report a Bug operator? It's kinda hidden away.

> - Finally, we could add an new field to those meta-data for maintainers? This could be useful if maintainers put in their `developer.blender.org` ids, then we could make use of add-on's Report a Bug operator and automatically assign maintainers to reported bugs. But then does anyone actually uses add-on's Report a Bug operator? It's kinda hidden away.

Campbell Barton commented

2021-01-08 01:15:52 +01:00

Since this is for bug triage & patch review - making users manually enter the name of the developer to when creating bug reports seems like something that would be ignored often, or could be mixed up as users have similar names.

From a quick check of 20 add-on reports - a little over half were created using the add-on bug report template which seems high enough to me.
Some of the reports that didn't were fairly incomplete, people making those kinds of reports probably wouldn't make use of the maintainer list in most cases anyway.

We could include phabricator usernames in the authors list for anyone who would like to be notified when bug reports are made to an add-on.

This way anyone reporting bugs from within Blender will create a bug report that assigns anyone on this list as subscribers, eg:

Some Name (@some_name), Another Name

... it may seem odd to have some usernames set and not others, so we could make it more explicit:

Some Name, Another Name (maintained by @some_name, @another_maintainer)

This would automate adding subscribers for bugs, for patches it the names would still have to be manually assigned.

Since this is for bug triage & patch review - making users manually enter the name of the developer to when creating bug reports seems like something that would be ignored often, or could be mixed up as users have similar names. From a quick check of 20 add-on reports - a little over half were created using the add-on bug report template which seems high enough to me. Some of the reports that didn't were fairly incomplete, people making those kinds of reports probably wouldn't make use of the maintainer list in most cases anyway. We could include phabricator usernames in the authors list for anyone who would like to be notified when bug reports are made to an add-on. This way anyone reporting bugs from within Blender will create a bug report that assigns anyone on this list as subscribers, eg: `Some Name (@some_name), Another Name` ... it may seem odd to have some usernames set and not others, so we could make it more explicit: `Some Name, Another Name (maintained by @some_name, @another_maintainer)` This would automate adding subscribers for bugs, for patches it the names would still have to be manually assigned.

Mikhail Rachinskiy commented

2021-01-10 03:16:23 +01:00

...making users manually enter the name of the developer to when creating bug reports seems like something that would be ignored often...
...over half were created using the add-on bug report template which seems high enough to me.

What I meant is to make a better use of specific Preferences > Add-ons > Addon preferences > Report a Bug button, not generic Help > Report a Bug.
Operator could have an optional attribute, that if set will form a url including maintainers id's and automatically assign them to created task.
But this button is hidden so far away, I doubt that majority of users will ever use it.

We could include phabricator usernames in the authors list for anyone who would like to be notified when bug reports are made to an add-on.

This way anyone reporting bugs from within Blender will create a bug report that assigns anyone on this list as subscribers...

Will it assign maintainers from all add-ons as subscribers to created bug report? Or it will only assign maintainers from one specific add-on that was reported on?

> ...making users manually enter the name of the developer to when creating bug reports seems like something that would be ignored often... > ...over half were created using the add-on bug report template which seems high enough to me. What I meant is to make a better use of specific `Preferences` > `Add-ons` > `Addon preferences` > `Report a Bug` button, not generic `Help` > `Report a Bug`. Operator could have an optional attribute, that if set will form a url including maintainers id's and automatically assign them to created task. But this button is hidden so far away, I doubt that majority of users will ever use it. > We could include phabricator usernames in the authors list for anyone who would like to be notified when bug reports are made to an add-on. > > This way anyone reporting bugs from within Blender will create a bug report that assigns anyone on this list as subscribers... Will it assign maintainers from all add-ons as subscribers to created bug report? Or it will only assign maintainers from one specific add-on that was reported on?

Mikhail Rachinskiy commented

2021-01-14 13:04:40 +01:00

To clarify: this discussion is only about establishing maintainers information, automation for phabricator is not a part of it and can be decided upon later.

Since I am the only one who was in favor of maintainers list similar to module owners, I guess this proposal is out of the way.

Introducing new entry in add-on meta specifically for maintainers is not getting support too, so using existing authors entry seems like a consensus.

I prefer this variant:

Some Name, Another Name (maintained by @some_name, @another_maintainer)

It is explicit, clearly states the purpose and using phabricator usernames means no confusion with name similarities.

If everyone agree, let's make it official and add it to documentation.

To clarify: this discussion is only about establishing maintainers information, automation for phabricator is not a part of it and can be decided upon later. Since I am the only one who was in favor of maintainers list similar to module owners, I guess this proposal is out of the way. Introducing new entry in add-on meta specifically for maintainers is not getting support too, so using existing `authors` entry seems like a consensus. I prefer this variant: ``` Some Name, Another Name (maintained by @some_name, @another_maintainer) ``` It is explicit, clearly states the purpose and using phabricator usernames means no confusion with name similarities. If everyone agree, let's make it official and add it to documentation.

Raimund Klink commented

2021-02-01 09:44:59 +01:00

Added subscriber: @Raimund58

Damien Picard commented

2021-02-20 22:33:27 +01:00

Added subscriber: @pioverfour

Damien Picard commented

2021-02-20 22:33:27 +01:00

Including Phabricator usernames in metadata would be extremely useful to automatically notify maintainers; I have to resort to searching reports for those add-ons I maintain once in a while, and some reports stay unaddressed for a bit.
Some information on maintainers is available from the manual’s add-ons section, but it’s far from complete, and possibly outdated.

Including Phabricator usernames in metadata would be extremely useful to automatically notify maintainers; I have to resort to searching reports for those add-ons I maintain once in a while, and some reports stay unaddressed for a bit. Some information on maintainers is available from the manual’s add-ons section, but it’s far from complete, and possibly outdated.

Sign in to join this conversation.