Improve module pages / roles

Hi everyone,
in the last week I worked on possible improvements for the module pages / roles. You can find the notes here: User:ThomasDinges/ModuleImprovements - Blender Developer Wiki
These changes try to address two main topics:

  • Make it easier for (new) contributors to find information about a module, its status and how to connect with developers. Also make the way these information are presented consistent across modules.
  • Strengthen and clearly define the module roles, especially the role of artist (QA) members and how they can help in the development process.

Feedback is very welcome.


One thing that springs to mind for me, as a new developer starting out with some bugfixes, is some help to determine which module you should pick.

It’s probably communicated in a thousand places, but if you’re new to the project it’s often unclear to which module a certain sourcefile/improvement/bugfix belongs. Maybe that happens more than ususal to me because I’ve mainly been busy with fixing crashes and stuff like that… For now I’ve mainly just run git blame to see who originally wrote the code and tag them as reviewers. But that won’t work if I ever happen to work in old code for which the developer is no longer an active member of the project.


Happy to see you work on this :slight_smile: We already discussed these things in person, so I’m just gonna give feedback on what I see on the page – and the relating Module Roles page.

Landing Page

Clear roadmaps are important, but last time we tried that it didn’t work out well. I’m talking about the roadmap images where we outlined projects to work on for the next releases. IMO it was a mistake to make the roadmaps release based, rather than project based. After 2.8, devs agreed to switch to a process that’s more focused on merging features once ready, not based on releases and release cycle deadlines.
There was a discussion with proposals here: Proposal to remove module roadmap images.

(BTW, in the past Ton raised the point that the module page on the Wiki should contain more info about the module. Devs seem to be more in favor of using the project pages for such info, so better check with Ton what he thinks of this.)

QA Members

The addition of QA as one of the (if not the) main responsibility of artist members seems to have been added some weeks ago, with no public notice of it (e.g. no announcement in the notes of that week or before/after).
This is a significant change in the role, and it puts the artists into a much more reactive, much less proactive position. Having some role for QA may be quite helpful, no doubt. But the IMO most important role for artist involvement isn’t really addressed anywhere now. That is, we need competent users who can help us create better designs in the first place. Designs that follow a coherent bigger picture while being highly practical. For that, they need to be involved from the first day of a project until a product is well polished and evaluated sufficiently.
Maybe this role should be filled on a per project basis, not on a per module basis. But having them actively involved in modules already makes things much easier (we know where to find the artists and they don’t need to find their way around first). Either way, this role is missing in the organization currently.

On another note, if you lookup QA job descriptions, these are usually quite “dry” jobs. It involves lots of work with measurements, protocols, automation, statistics, … Even if we keep it more basic, I doubt that we will find anywhere close to enough artist members that are enthusiastic enough about testing basic functionality all day long with no artistic outcome. At least not volunteers.


Hi @julianeisel,
thanks for your feedback! :slight_smile:

  1. I checked your proposal and like it. Having a list / workboard whatever of current and planned projects with some progress indication is fine. My point about the roadmap is more to have an updated one. Many modules still have the outdated graphics for 2.9x.

  2. We could have artist members on a per module basis for general testing, feedback and example artwork for release logs etc and then assign them (or others) on a per project basis for bigger features / designs. So basically keep the work fun and give volunteers a chance to participate with a bit of time, but allow for more involvement if possible.

Btw: I’ll collect all the feedback and once the picture gets clear, make examples how it can look like in practise for landing pages etc.

@Baardaap Hi!
It’s not always clear, who should be added as reviewer indeed, git blame is a good way to see who worked in an area recently. Modules - Blender Developer Wiki is a good starting point too, and then pick the people who are listed there in the respective areas of your patch / bugfix.



This seems to align with what we have been doing, but not consistently enough for every module. So overall looks good to me.

Inactive module status and communication around that generally does not happen exactly because it is inactive. So I guess you or someone else would need to fill in those gaps.

For the landing page, I would prefer to move basically everything to the project page. Having two places with approximately the same info is likely to go out of date.

I would get rid of the roadmap images on all the module pages also. They are all outdated and I think it was a bad idea to have them in the first place. Trying to predict which features go in which release to this extent is missing the point of the rolling release schedule, and incompatible with the horizontal organizational structure that we have. Instead I think it’s more useful to have workboard columns that communicate what is under active development and what the order/priority of other tasks is.


Thanks for your feedback Brecht!

Inactive module status and communication around that generally does not happen exactly because it is inactive. So I guess you or someone else would need to fill in those gaps.

I can communicate about inactive modules, that’s fine.

For the landing page, I would prefer to move basically everything to the project page. Having two places with approximately the same info is likely to go out of date.

You mean only have module info on then and simplify the wiki page? Modules - Blender Developer Wiki That page could only link to the landing pages then, I agree that having this info in two places will make maintenance more difficult.


Yes, the wiki page could just link to the pages for the most part, except perhaps a few things like the Blender and Triaging sections.

1 Like

When considering whether these landing pages should go on the wiki or dev, I think we should consider where people are landing from. I think it much more likely that they will come from wiki pages than from phab, which we are going to be replacing.

And note that no matter where these go there will not be any duplication of the information. The current Modules page would become a simple list of links to each of them no matter where they live.

My only real objection to using phab for this are the current lists of Members and Watchers in the right column. If these can be removed then they seem fairly equivalent. If they can’t be removed then they will remain a strange duplication of the members that we can’t add more information to for clarifying roles.


Hi Thomas, since you seem to be asking for feedback from all developers, here are my thoughts.

  1. For the module status, the traffic lights indicating status sounds like a good improvement, and if the submodules can also have a status, then I would expect that to be indicated too. I assume you’re planning to add that table describing the different states to the top of the modules page as well :wink:
    Note: do make sure that the status is also listed as a row in the main body of the module as text because red/green color blindness is a thing and that could cause some rather severe mix-ups :stuck_out_tongue:

  2. Generally sounds good to me. I agree that the landing pages should just be in one place so that info isn’t duplicated.

  3. I wouldn’t use the term QA. QA is a specific job, with specific responsibilities, that do not coincide with what is provided by artists. I would stick with the term ‘Stakeholder Artist’ or Artist Members. Also, their primary role should be driving feature development, this would consist of suggesting features and providing feedback to the developers in the module. What you’ve mentioned can definitely be a part of what they do, but shouldn’t be their main focus. IMO, what you have suggested basically represents them as lackeys for the developers (which is a job that, for the most part, could be filled by almost anyone) and is a waste of the incredible resource that they are (especially if they are studio/industry artists). During my development of the Collection Manager add-on, I have been lucky enough to work with what I would call a ‘Stakeholder Artist’ and it has been a very symbiotic and beneficial relationship, and because of their feature suggestions and feedback, the add-on is in a much more polished and useful state. Now, the jobs you have outlined are needed, but for that I would have a separate ‘General Members’ role. This also makes the module more accessible to people who want to help out, but may not fit into a developer or artist role.

Since it also sounds like you’re open to discussing module policies, I’ll offer some feedback for this as well:

  1. I believe that modules/submodules that are in maintenance mode, inactive, or are deprecated and will be removed shouldn’t be frozen, people still depend on them and can benefit from new features and bug fixes, however since they won’t have any reviewers there should be a higher bar for contributions to those areas. I propose to change it to anyone who submits to an area that is in one of these states must be an active contributor and willing to maintain their changes for at least the next year. While this does carry some inherent risk, it also allows for the chance that the area can be revived and for some really great improvements that would otherwise be lost. (And for the areas slated to be replaced, then even if the code is bad it’s going to end up being deleted anyway :wink: Just make it sure it’s clear that that area is going to be removed, of course.)

  2. N/A (Only here because list item #2 apparently can’t be skipped. Thanks devtalk :roll_eyes:)

  3. Speaking of feature requests. I’m so glad you mentioned them, because from what I’ve seen, the absolute no feature requests, you can post on rightclickselect but we don’t have to look at them, rule has led to the community feeling ignored in what is supposed to be a community driven project. I would really like to see feature requests become well integrated with development. I personally take feature requests with my add-on and have found them to be beneficial and increase involvement from the community in my add-on. That said, I haven’t gotten to all of mine yet and sometimes what’s being asked is impossible or isn’t very well thought out, etc., or sometimes I have other stuff that I want to prioritize, but at least the users are heard and I have more information that I can utilize. I personally would like to see a ‘Feature Request’ tag in Phabricator (or whatever platform is used) that can be applied to tasks along with tags to what area it’s directed at. This way you have an easily searchable conglomeration of feature requests that can be pulled up when needed for whatever areas you want. This would probably cost more overhead for the triaging team, but I think if you put out a call for feature request triagers to the community on blenderartists, #blender on, the Blender discords, reddit, etc., that you’d find tons of people willing to help out (you’d probably end up with more bug triagers too :slight_smile: )

I hope this is helpful.


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,


Hi @ThomasDinges,

Thanks for handling this. I globally fully agree with @brecht thoughts here.

1 Like

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 :slight_smile:

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 :slight_smile:

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


Finally took a moment to check out the updated proposal in more detail. Generally something I can get behind. Just two points of feedback:

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

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

1 Like

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 :slight_smile:

1 Like

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? :man_shrugging:

After a discussion in blender-coders on, 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 and offering to step up as a maintainer for that area/module, that this be clearly stated on the Modules wiki page.