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.
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 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 developer.blender.org 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.
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.
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 developer.blender.org 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.
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 developer.blender.org project page. Having two places with approximately the same info is likely to go out of date.
You mean only have module info on developer.blender.org then and simplify the wiki page? https://wiki.blender.org/wiki/Modules 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 developer.blender.org pages for the most part, except perhaps a few things like the Blender and Triaging sections.
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.
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
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
Generally sounds good to me. I agree that the landing pages should just be in one place so that info isnât duplicated.
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:
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 Just make it sure itâs clear that that area is going to be removed, of course.)
N/A (Only here because list item #2 apparently canât be skipped. Thanks devtalk )
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 libera.chat, 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 )
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.
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.
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.
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.
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â. https://wiki.blender.org/wiki/Modules#User_Interface
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.
We already discussed these things in person, so Iâm just gonna give feedback on what I see on the page â and the relating 
)
