Add-on maintainers list #84471
Labels
No Label
Interest
Animation & Rigging
Interest
Blender Cloud
Interest
Collada
Interest
Core
Interest
Documentation
Interest
Eevee & Viewport
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
Import and Export
Interest
Modeling
Interest
Modifiers
Interest
Nodes & Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds, Tests & Devices
Interest
Python API
Interest
Rendering & Cycles
Interest
Sculpt, Paint & Texture
Interest
Translations
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Meta
Good First Issue
Meta
Papercut
Module
Add-ons (BF-Blender)
Module
Add-ons (Community)
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
5 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender-addons#84471
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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?
Changed status from 'Needs Triage' to: 'Confirmed'
Added subscribers: @MikhailRachinskiy, @ideasman42, @dfelinto, @mont29
Personally I would add a way to tell who is current maintainer of an add-on in its meta data:
- [x]
or so).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?
There would be no way to tell authors and maintainers apart, if add-on has more than one maintainer.
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.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.
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.
What I meant is to make a better use of specific
Preferences
>Add-ons
>Addon preferences
>Report a Bug
button, not genericHelp
>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.
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?
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:
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.
Added subscriber: @Raimund58
Added subscriber: @pioverfour
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.
After launch of extensions platform this proposal is no longer relevant.