I don’t think it matters much where the landing pages will be. The point is to have one central page with all important and up to date information. This is not the case at the moment, some information is on the wiki, some on devtalk, some on Phabricator.
Details can be discussed of course and maybe it’s possible to make the layout of the phab pages better.
Hi Ryan,
Thanks for your feedback.
There will be an explanation and text of course, for everyone to understand.
The term QA popped up on the wiki a few months ago, but there wasn’t a proper discussion or decision about this yet. It is important to clearly define this role. What should it be called? What are the tasks? Who can help? How much time should a person have for this?
One of the reasons I brought this up is that the term “Artist member” always felt a bit intimidating for me personally. Somehow I associate people with this role, who worked on the Open Movies and can create phenomenal art! I think there are very talented, technical people who could help here as well. People who are not programmers, but have a good technical understanding of how a feature could or should work or can provide good examples (test scenes or content for release notes). I hope for further feedback here, and get a better idea what we need and how we can involve more people.
A module in “maintenance” mode, doesn’t mean no one can work on it. It’s more an indicator for everyone, to better manage expectations, especially for patch review. People are listed as maintainers, but when you ask around you learn that the person hasn’t been seen in months. This can become very frustrating for new contributors who just submitted a patch and hope for review.
If someone wants to step up and become an active and longterm! maintainer of that module, ideally an active contributor who can provide features that are in line with Blenders philosophy and standards, everyone is welcome to do so.
I’ve seen a few feature requests on RCS that ended up in Blender. Even though we have more developers than 10 years ago, the community has grown as well and there are more requests than ever. This is why I suggested an “Artist member” (or whatever we call this role in the end) can help with that and for example check on sites like RCS, identify the most wanted request(s) and talk with the developers if and how these can be incorporated into a longerm roadmap.
Best regards,
Thomas
Hi @ThomasDinges,
Thanks for handling this. I globally fully agree with @brecht thoughts here.
Indeed, a very interesting question.
Artists - Developers relationships world is definitely polar (it has ART and MATH poles), so I, as a workflow designer tried to map this world to be able to operate with it during software using/development cycle.
My best assumption at the moment which could possibly take into account abstractions levels is a supersymmetry model of those relationships which I can schematically depict like that.
From this map it is possible to see that artists demands depends on their abstraction level.
For example, the level of a technical demands and general possibilities of a technical artists who are close to manual production are different from demands of a general compositional artists, and since they are focused mostly on a local tasks none of them are focused on general pipelines, which is a pipeline management job.
Compositional Artists are naturally farther from development abstraction level than technical artists as well, so technical artist can provide technically deeper feedback, but for a limited scope.
In short, artists are very different (by skills, technical and workflow range demands), and this probably better be taken into account.
Tell me, please, what do you think about such a map.
Hey, sorry for the late reply, I had a busy week.
Excellent! I was just double checking 
While the role you’re looking to create, and it’s responsibilities, hasn’t been defined yet, the term QA has (Quality assurance - Wikipedia). So unless you want to stick to the standard QA definition, I wouldn’t recommend using it as this will only cause confusion and potentially drive people away who don’t want to basically, just test stuff.
I think this is a good thing, to some degree. What developers need to properly drive features is people who work on large scale productions with real world experience (think Blender Studio and up, as far up as possible), those who do something 1000s of times a day and can identify whether features are working properly and what the pain points are. Now this isn’t to say that hobby, freelance, or small studio artists can’t provide valuable feedback, they most definitely can and are needed as well, but ideally there would be a mix of the two types with the lower end overlapping with another more general module role that’s open to everyone.
Note: Although the term we are using is “Artist” I don’t mean to imply that this excludes CAD or other types of Blender usage, those who work with that kind of thing, especially at a high level, are needed too
But since there is effectively no one around to review it, doesn’t that mean that no patches will be allowed in? What I suggest is to skip review for these patches and just merge them to master provided that the author is at least somewhat known (you may have to ask them to introduce themselves and do some other small development first to prove they aren’t malicious) and agrees to stick around to fix anything that may break for a reasonable amount of time.
This would be ideal, but I doubt that many people would be willing to just jump in to maintaining a module right away. I think it’s far more likely that someone would make a few small contributions to an inactive, etc., module to test the waters before considering the jump to long-term maintainer. (But they can’t do this if none of their patches make it in because they’re left in review limbo)
This is true, but iirc, this has been relatively, very small. Plus I’m sure that I’ve heard something along the lines of “users can post to RCS all they want, but nothing says we (the devs) have to look at the feature requests there” several times in the past from people such as LazyDodo (iirc, apologies if I’ve got the wrong person). Stuff like this has made it so that I always feel guilty pointing people to RCS, because it seems like RCS is where good ideas go to die. And, this is why I’m really happy to hear about plans to have RCS more regularly reviewed, however, I think it would be more useful to me as a developer to properly integrate feature requests into Phabricator with a dedicated tag (and I think that would make organizing them in an advanced search (or workboard?) a breeze), but that’s just my current take on it.
While curation of feature requests is most definitely needed, I’m not sure I’d use the “Artist Member” role for that, I don’t think those with the experience to be Artist Members would need to go looking through RCS to identify Blender’s shortcomings or understand what features are needed. I would have feature request curation as part of the responsibilities of a “General Member” role.
All the best.
Finally took a moment to check out the updated proposal in more detail. Generally something I can get behind. Just two points of feedback:
Referring to non-active modules:
For critical issues (like crashes), the core developers can take a look, if the issue is considered severe by the admins
Does that mean admins are responsible for finding severe issues in non-active (“red”) modules? That seems like quite a burden loaded onto them. I’d say the triaging team can just do this, if in doubt core developers or admins can help out with their judgement.
As example for the channel header, you use #geometry-nodes as an example. I think that’s okay to demonstrate the point, but I’d note that this in fact is not a module channel, but a project channel. We should always be very explicit about this difference (especially since a project may involve multiple modules). By the way, as naming convention I’d propose using -module and -project suffixes respectively.
Actually, thinking about my second point again: In fact #geometry-nodes started out as project channel, I’m not sure what it’s now - a sub-module channel I guess? (Personally I think these can work well, it did/does for the #xr channel, which is officially a sub-module of EEVEE & Viewport.)
Rest of what I said for point 2 still stands
I also cant agree that “Artists” is a nice term, it looks like a strong affiliation segregation from “Users”.
Art is generally software independent, you can make an outstanding art without using computer at all (there are lots of known cases museums filled with).
Software naturally stands for solving production demands by using computational power, which in most cases is presented (ends up) as a lots of technical work rather than making specifically art.
For example, the number of specific commercial positions such as “modeller”, “rigger”, “groomer”, the result of which is more related to technical production than art, are represented in the industry much more often than “artist”.
The problem with the term “Artist” is that it can be taken quite literally.
I encountered this a couple weeks ago. I wanted to add some people to the User Interface module, mostly so I wouldn’t forget their names and would no longer have to rely on “post-it” notes. LOL. But many did not fit an “Artists” heading there - even though they might be - since their roles were more like testers and consultants. I ended up just using “Other Contributors”. Modules - Blender Developer Wiki
Okay, so maybe “Stakeholder Users” then? 
After a discussion in blender-coders on blender.chat, I’m revising my feedback on inactive/maintenance/deprecated modules to include that since there apparently is already a policy for people to contribute to inactive areas by talking to people on blender.chat and offering to step up as a maintainer for that area/module, that this be clearly stated on the Modules wiki page.
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
