Stakeholder term means having and holding stakes - the production demands, like basepoint snaps for precise modeling in architecture or pixel margin UV packing for baking in gamedev.
Higher demands mean higher stakes.
It sounds like it is a special role that differs from other roles of a direct development assistance.
Also not sure about color scale.
(Red is the color of urgency, the color of inactivity/neutrality is mostly grey)
I think it is a special role because as it has been used up until now it has been more about systemsâ design than developmental assistance. The artists/users have driven the design of the features and fixes to suit real-life production demands, and I think this is a very needed aspect of a module. The role in Thomasâ proposal seems to me to be a new, redefinition that is more in line with general development assistance. In the end, I think both roles are needed and should be included.
I also agree that grey is more often associated with inactivity. Although, red is often used as stop/danger/bad/etc., so maybe it should be used for end-of-life modules or to indicate a module is in desperate need of members.
Hi,
in order to get things going, Iâd like to focus on the landing pages and status for now. The role definition needs more work and will be handled afterwards.
I updated my proposal a bit: User:ThomasDinges/ModuleImprovements - Blender Developer Wiki
Simplified the status, only have active / inactive. I think that is easier.
Add Meeting infos to the landing page as well.
I also created an example landing page, that can be used to create a template.
I kinda like the Animation & Rigging module page, but I am open to suggestions. In the end the template should only provide a minimal basis. Every module is free to add additional information of course.
Once there is an agreement on the basic template for the landing page, this can be implemented by every module within a small time frame (~1-2 week). Modules that miss that deadline will be set to âinactiveâ until someone steps up. There will be a proper announcement on the ML once this is starting.
Best regards,
Thomas
Maybe itâs necessary to specify what the status means to the contributor? Eg. what happens if a contributor submits a patch to this module in its current state?
Seems to me that in your example crucial things(from the Animation & Rigging landing page) like tagging the patch correctly are missing?
Bug reports and patches are to be tagged with Animation & Rigging
Speaking of colors - a nice example when red is already used for depicting urgency.
https://developer.blender.org/T93220
It make sense to keep color schemes consistent across system.
Hi @tintwotin
There will be information what active / inactive means, including what it means to contributors.
Yes, my ModuleExamplePage is not finished yet, I aim for something like the Animation & Rigging page, but wanted to wait a bit for further feedback before finalising the example.
In case anyone is unaware, it seems that Thomasâs proposal has received some significant updates after getting feedback on blender.chat, predominantly to section 1, and he is hoping to go ahead with it if there arenât any objections [Bf-committers] Updating Module pages
Hi,
yes indeed, the proposal was updated and already discussed with BF admins. The wiki page will be simplified, and all relevant info will be on the landing page itself, reducing duplication. In comparison to the current landing pages they will also have info about the module status, list the owners/members and link to meeting notes (if the module has meetings).
What about submodules? Should there be information on those too, or should all of the info be on the main-module landing page? In the submodules, there might be different statuses, contributor requirements, communications, meetings, plans etc.? Asking because I noticed that most of the submodule info was removed in the VFX&Video modules recently: VFX & Video
Submodules can have their own info, meetings etc. if needed.
Considering that Phabricator is end of life, and will be replaced with another solution in the future, I wouldnât spend too much time on details now. The latest proposal addresses two main points: Avoid duplication between the wiki / phab page and provide more information on phab about module status, members, meetings etc. And the points that should be mentioned on the pages, are minimum requirements. Every module (or submodule) is free to add additional information. Just keep them up to date and communicate well whatâs happening.