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”. Modules - Blender Developer Wiki
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 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.
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?
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
)
)
