Making a dedicated topic following some thoughts voiced out on the big Blender Sculpt Mode thread such as:
Taking a bit of a tangent here:
From my little professional experience working on animated movies / VFX: every department have one or multiple supervisors, and also productions coordinators. While the supervisors are basically the over-lead of their department on both artistic and technical planes and are the face of the department to other departments, prod coords are the interface between the supervisors and virtually anybody else. They are the supesā second brain, their schedgule organizer and assistant, the bug reporter, the ones we talk to first before the supe. Not for gatekeeping, but to keep the supervisorsā time used optimally.
I donāt know if this makes sense in a software development environment, but I could imagine a similar system for Blender.
Having someone or a team dedicated to be the contribution buffer, weeding out the things that canāt make it for broad reasons common to any module, helping contributors refining their stuff, directing to the appropriate resources they need, and making the communication bridge between contributors and the concerned devs when a contribution is ready for it. Kind of a contribution-specialized community manager 
1 Like
@Ace_Dragon
As far as I can see, those are more or less trivial things to do, which the developers will have to check anyways again for the review.
To me, this feels a bit like trying to make it more efficient by adding bureaucracy which I am skeptical would achieve the desired outcome.
Edit: It might be that the core developers would only check the code, whether it works, ā¦ and once they are okay with it, they may pass it on to someone being nitpicky about consistency, variable names, ā¦ . However, I donāt check the review enough to know whether this is actually a bottleneck that would be worth addressing.
Wasnāt there some effort around after 2.80 release to fix something like 500bugs before starting new tasks?
If I remember correctly Dalai was in charge of that thingā¦
Idk, maybe itās a common thing or it has nothing to doā¦
But after a certain accumulation, maybe there could be some rule that would force work to be reviewed before developing new things.
I am annoying with this and itās semi-on topic but also from my studio experience, from time to time artists in production can participate in surveys and AMAās and production take notes of large issues that get reported if they are general bottle necks.
I am not talking just surveys to make people ventilate, I talk about noting problems or frustration that are common to everyone.
Sometime during these sessions riggers or TDās realize from the first time these problems exist and most of the time can come up with quick, efficient and durable fixes with little work short time after.
I feel thatās already a process between open movies artists and developers but I am wondering if broader use of this process could be applied using larger pool of people.
More interaction/communication between devs and users is maybe not necessary but I personally appreciate it a lot.
I really liked that Joe was exchanging with us in the big sculpt thread for example.
That second point might not be that off-topic after all, if there would be more communication in both directions between devs and users it could help make the contribution process more understandable and efficient, maybe even inciting users to consider contributing more.
Yes, that was the Tracker Curfiew:
I wonder what are the current stats of daily bug reports. From 2010 to 2018 it was oscillating roughly around 200-450 bug reports per month, and then it skyrocketed to 800-1300. Scary.
I donāt know if it was Dalai āin chargeā nor in which way, all his article says is:
A dedicated triaging team (Germano de Souza, Philipp Oeser and soon Richard AntalĆk) will be full-time triaging reports. No bug fixing will be done by them while there is any untriaged reports around.
I donāt see how this would be practical, because reviewing code is not a streamlined process in general and especially not in a public open source project. There are cases where a discussion among developers has to take place, whether certain features are even wanted. After all, once code is in the main branch, it has to be maintained. There may be a discussion regarding the software design, about how it is integrated and whether that is the appropriate way. Then, there are usually things that need to be corrected, meaning, they have to wait for the original author.
Code review is often a back and forth. And it is not clear how long it takes beforehand. Thatās why I donāt see how you could put restrictions onto developers in that regard.
Some developers use https://devtalk.blender.org/ to ask for feedback. If someone wants to work closer, they may ask to join module team as artist: https://wiki.blender.org/wiki/Modules/Roles. Sometimes, they also have workshops.
Some developers like it more than other to get more or less feedback, but that is also dependent on the task.
The communication has to be initiated by the developers if they believe it is needed. In the other way it has to be very restrictive, otherwise they would be flooded with feedback they likely donāt need or want. An exception here would likely be module team members.
2 Likes
If thereās something like 1000 patches the authors or the community believe are āready to be added to blenderā, you canāt have a Blender employee assisting all 1000 external devs. There should be a limit of like 10 to 50 slots per year where people who get a slot can be sure they will get to have a conversation with assistant to the core dev about their patch.
There could genuinely be 1000 rock solid ready to go patches right now, thereās no way to review all of them in a reasonable amount of time and no way to not make the authors or the fans of the proposed features from feeling sour and griping all over the forums about feeling ignored. But if they know thereās only a limited number of spots on a first come first serve basis (which will also piss off people who think their feature is more important than life itself) then some people will be able to think and behave more patiently.
2 Likes
I remember that time Ton asked for a hand raised vote for one feature to be implemented after a conference in BCon.
It was made as a joke and was nothing very official.
I still think some democracy process could help push some features in an effective and frictionless manner.
After all, if users have a direct way to filter what can be done or not - to some extent - that could be a way to avoid frustrations and to establish the way.
I am not saying users should control everything, maybe just give them voting power on special occasions when there needs to be a decisions made on which way developers should go.
Not all the time.
Like if it was clear a majority of users wanted dyntopo reviewed and out asap, maybe more ressources couldāve been allocated to that?
I am always pushing for democracy stuff and I agree it might be an awful solution (or not).
I just think there must be a way or multiple ones to solve that code review thingā¦
I am a simple user and I donāt even program at all. Maybe I am wrong but it really feels like, from my understanding, that the mentioned lack of code reviewing thing seems to be responsible for loss of precious code and a source of friction between people at all levelsā¦
I guess there really needs to be a confirmation of the problem by people who know how this stuff works before anything.
I donāt know if this forum is the right place to discuss this isnāt this all available via blender.or:g get-involved and New Developer Info and so forthā¦ ?? Also there are hints about how to start doing some something about smaller issues for the project (like in all other projects too) so someone can get used to it and become known to the developersā¦
Iām somekind of bored about this āargumentsā: the devs refused my suggestion/proposal/patchā¦ ā¦well thatās the general problem within something where multiple people are involvedā¦ one single person isnāt the majority of those who do manage itā¦ but if any suggestions is reasonableā¦ i donāt believe the people at the Blender Foundation do refuse it because just for funā¦ sometimes it may also just have been forgotten or falsely reimported while doing some patchingā¦ shit happensā¦
Think of your actual govermentā¦ you voted it ( and donāt come with the argument that you voted for the other political party !! ) andā¦ nooo they donāt listen to youā¦
This is like pretending that all this isnāt there and impossibleā¦ (again the sources are openā¦ so use them )ā¦
I just donāt understand those claims: XY is unusableā¦ (and now the whole project is on the downfall) something like that comes up everyā¦ month, weekā¦ and than this āthis has to be changedā ā¦even when sometimes it is clearly stated that it is in developementā¦or the devs do say they have to investigate the actual usage moreā¦
But then againā¦ iām also just a single voiceā¦ and seem to doesnāt change any opinions about the slothiness of the blender developmentā¦
<irony>
ā¦ bbbbuuttt wwwaaiiitttt mmaaaayybbbbee yyyooouuuu aare jjuuussttt tttalllkinnngg tooooo ffffassttttt
</irony>
3 Likes
The only way this could work, is if the developers suggested some high level, general directions. We can either focus on this or on that at first.
The directions would need to be suggested by the developers, because they have a better idea of what is doable and what not with their available resources and what the individual developers can do.
That is literally micromanagement. This is simply ridiculous, sorry.
You want to intervene when they do something you donāt agree with. No one of us knows whether the situation was caused by a lack of resources for the review or possibly something completely different.
2 Likes
True, that kind of system can help.
I imagine the ācontribution managersā could organize sort of events. Much like the tracker curfew or the different workshops on specific subjects the BF sometimes organizes, we could have āsnapping tools monthā and āui papercut for next versionā and whatnot, to also help focus on some subjects. (plus it will make it simpler to document on the release notes lol)
In the two companies Iāve worked with, itās kind of on a daily basis.
I like how the Animation 2025 has been handled so far. It basically started by probing the community and went from there.
And if you read this:
Especially āDocument the āWhyā of Design Decisionsā, that sounds like another move that will greatly help with contribution.
Overall, I think having communications both ways and overall transparency is really needed.
I donāt know where else it would be better. Blender chat maybe, though the chat format is prone to have the subjects drowned by others
Devtalk would have been a nice place, before april.
I feel like the rest of your message went on a tangent. Just to clarify: this topic isnāt about antagonizing the BF or contributors, nor to complain or point fingers. Itās more about thinking of a system to help contributions overall. By making it more manageable for the current devs, and adding more community guidance.
I think most people who help Blender in any way are aware of the documentations and
But, as you also mention: āshit happensā, in many ways and reasons. Think about this very forum (or any other): there are clear rules and usage guidelines, yet they will all be broke many times by many people, and unintentionally most of the time. In those cases, we can let it happen, or shepherd-back to the point, or cutoff the strays? I think this topic is about strengthening the shepherd.
2 Likes
Yeahā¦ it seems that āpeopleā where talking on the forum whoā¦ wellā¦ to be diplomaticā¦ where eating up dev timeā¦ and so this step was neededā¦
ā¦to much talk of people believing they have to say something importantā¦
ā¦
Yes i knowā¦ there where and are some people which arenāt even able to do a simple searchā¦ evenif they found there way into this forumā¦ they doesnāt about netiquette ( or even know about it)ā¦ :
Listen before you askā¦ your problem may not be the first and may occuredā¦ just yesterdayā¦
ā¦and please have a look at the faboulous manualā¦
ā¦and moreā¦
But neverthelessā¦ this forum is to help BlenderArtists and also is often suggested in devtalkā¦ and it is devtalk not usertalkā¦
Also i think itās kind of weird to demand that blender does act more like any other program or beginners lamenting about things beeing so hard in blender when in fact they didnāt understand some basics and so have problems they even would face using any paid addon ( which may have some better suited tools in some areas but also need some knowledge and experience to handleā¦)
And thatās it: people which lesser knowledge and experience in developement scream at those who do things: do it betterā¦
Of course software developers also have to learn things about the area they do developeā¦ thatās the reason why for example the ānext big thingā ( i actually hate this phrase ) will be the changes in the way animation and the of the underlaying data will be handled . . itās a (big) change in the architecture and internal management of resources in blenderā¦ and will take timeā¦
( This also applies to any sculpting features which blender originally wasnāt made forā¦ or the everything nodes approach and the ongoing comparison with ZBrush and Houdiniā¦ ā which are very specialized into this areasā¦!!! )
Puuhhā¦ it seems there was something pilling up in my mind a bitā¦ there are even several threads about some āthingsā about blenderā¦
1 Like
(sorry, couldnāt resist 
)
Well, thatās always gonna happen no matter what you do.
I bet I can find zbrush/houdini users claiming their software is unusable and itās dead and X or Y software does everything better and whatnot.
I like to assume you can find pretty much every opinion possible voiced out loud enough on the internet.
1 Like
yes off courseā¦ but sometimes itās too much what some people demandā¦ but if you say something like: grow upā¦ then you are the negative personā¦
which just proves the pointā¦
and thanks for the hugā¦
1 Like