Blender Democracy - User-request based development

Hi

About 3 months ago a discussion popped in the Meeting notes thread regarding user feedback and forces driving Blender development’s orientation.
One solution that wasn’t proposed is to instaure some sort of democracy system.

Would it be possible for users to directly vote for what paid developers work on, at least partially?
Something like Right-Click Select (RCS), but that would have a direct and absolute impact on what is worked on by paid developers.

It could start progressively, like users could vote to have 1 small bug per week fixed prioritary, one medium feature being worked on every month and one major feature being worked on every year.

Then some more complex stuff could be done, like users voting on priorities, the major R&D orientations…
Money from the foundation could be managed by this system to create bounties that would serve as an incentive to get developers working on certain features.

I am willing to update this post with peoples propositions if it becomes a thing.
If a thread about this already exist (please give me the link!) I will delete this one.

_

Here a some tools already existing and arguments that were mentionned in this topic’

  • Right-Click Select uses already filters posts by votes. It doesn’t mean the porpositions and arguments in RCS with most votes are done in priority but it gives them more visibility.

  • Tokens given at developer.blender.org can be a factor of influence, although it doesn’t have a direct effect on the decision making process.

2 Likes

I do not see the benefit of this. Currently, if you want something accomplished in Blender all you have to do is to do it, and show you can provide long-term maintenance. If you have neither the skills nor vision, what makes your opinion valuable.

Trying to micromanage such a complex system is doomed to failure. Those who are active in the community should have the most input. Lastly, look how well democracy has worked out for us so far.

[Edit: was typed on phone; fixed many typos :frowning:]

9 Likes

There’s a good reason why the average dev. team does not adopt a development model where they wait for the community’s input and approval before making so much as a bugfix.

The model would mean development becoming excruciatingly slow and inefficient, because everyone in the community has their own wants and many request threads often go for weeks of back and forth over whether or not the idea is any good. Then there’s the issue of how there’s a long list of todo items and not near enough devs. to get it all done at once, a model based solely on the community vote would have to decide what features are implemented in what order.

If there is enough demand for a feature gleaned from general development discussion (as seen today), then the devs. have noted that and have implemented a few of them providing it was practical. 2.8x meanwhile brought an increased rate of feedback turning into actual code and roadmap items (without compromising the rate of development).

5 Likes

The benefit would be to have paid development oriented towards what user wants and not toward what developer want.
Users are not all programmers and a lot contribute to development fund in hope it will shape up to their expectations.
A big part of it could be automated, actually RCS is almost already working, except that it as no real direct power.
There are many types of democracies. One where most active members would act as delegates pushing most popular topics could work too.
Poorly implemented democracy is as bad as anything poorly implemented.
Democracy should simply be seen as a tool used to help a group make decisions.
Maybe the developers use some sort of democratic process on developer meetings…
The thing is the users don’t have any right now.
We just have RCS that isn’t democratic as it’s purpose is not to come up with final decisions but only possible suggestions.

Wouldn’t mind a system where users could vote and pool their money for a specific feature or fix, but in practice, I think it’d take from the general dev fund, and would hate to see that happen.

If i’m voting, I’m voting for current system. I’m very happy with the pace of fixes and new features under current management. I have my own preferences that aren’t being addressed, but that’s fine as i don’t fully understand the intricacies or development process.

Democracies work well when you have an engaged and educated public and not convinced this describes most of the community that’d be voting. I can easily see misadventure by social media stars and organizations with their multitude of followers, or just bad decisions by general users who don’t fully understand why a stable extensible base is preferable to work on flashier features.

7 Likes

[quote=“Ace_Dragon, post:3, topic:1227410”]
The model would mean development becoming excruciatingly slow and inefficient, because everyone in the community has their own wants and many request threads often go for weeks of back and forth over whether or not the idea is any good.[/quote]
I don’t see how fixing one bug a week/per dev meeting period would be slow and inneficient.
Even if there is as much propositions as number of users, only one would be selected per period.

People can already do it, it’s only the platform that is missing.

If implented as you describe I agree with you that it would be very bad.
But there are infinite ways of implementing this, delegation to experienced and trusted users is one of them.

One aspect of democratic development is that a project such as Blender, is built on a finalities, that is delivering a wide purpose 3D application able to support the many aspects of 3D from modeling to video generation of final work. Each part of Blender requires specific skills, like for modeling where mathematical knowledge is key to program the tools that are effective in allowing to create complex shapes, or scientific knowledge to program color correction, texture generation and lighting simulation in addition to materials like cloth and water using physics mathematical models for simulations. Most of the users don’t realize that the functionalities that are implemented behind the UI are based on complex algorithms implementing scientific based laws… What users see or experience is most of the time glitch in programming at the level of the interface or rendering and these are most of the time issued from improvements done in other parts of the application and not foreseeable at the time of activation for the users. This is where bug related warning by users is key for a stable progressive development. If users don’t inform the devs about bugs, then the development cannot keep evolving the code without securing that the foundations are stable. Users are not the good source of directions, but they are key to warn about malfunctions and help to track down where and how they happen. Then it’s the turn of the devs to take over once a bug is located or identified and correct it. Regarding development of new features and functionalities, devs and the management are at the focus point where evolution of trends and needs are visible. From there they have the elements to decide of priorities and long term orientation, not users even if they, the users, are presented with long term planing and orientation… Users live in present time, they need to have the job done, and for that they need to master their specific skills that are beyond what the devs are seeing and seeking…

1 Like

The idea was not to give absolute power of decision to users but a small part of it.

A developer is assigned to fix a paper cut and he has to pick one out of two:

  • One requires basic knowledge and short time to fix.
    Fixing It has a huge positive impact on the workflow of hundred of people, even bringing new people to start using Blender.
  • Another one requires more advanced knowledge and is more time consuming to fix.
    Fixing it moderately benefit a dozen of people on using very specific functions.

Suppose he has the total freedom to pick of or the other and it is to his entire discretion, it is possible that he decides to fix the second one which would be unproductive.
A basic voting system would prevent that.

Again, this could be just a small part of the decision making.
A Paper cut a week voted by users. I only see benefits.

In reference to what users want: this is the point of the Open Movie projects - to have users and developers working together to add/improve features. Spring, I believe, was used to advance volumetrics (clouds, mist), and Hero was “a showcase for the updated Grease Pencil tools in Blender 2.80.” (https://www.blender.org/about/projects/) Each movie project adds and develops features in a way to make them robust and usable by, well, the users.

Additionally, Pablo Vazquez has done phenomenal work in “democratizing” input into Blender with over two years of live streams in two languages (not to mention his exceptional work since the whole covid thingy happened). He and other members of the Blender team are active on a variety of forums from Blender-managed ones (Blender dev forms, blender.community, etc.) to things like Twitter and Youtube.

Also, we should concern ourselves here with features only, not bug fixes. Bugs need to be fixed even if only one user notices them; this should not be a matter to be voted upon. The tacker curfew instituted by Dalai Felinto did great work in bringing the number of open bugs down, and the new development cadence including long-term support releases is another good step. Fixing bugs is a gnarly business, and cannot be scheduled; sometimes it just takes time (and a bit of luck) to figure out where in the code base a misstep was made.

Having a hundred thousand voices asking for improvements to the outliner is not automatically better than having 100 people asking; the devs can only do so much. And as mentioned elsewhere on this thread, hopefully Ton et al have a plan, and though they need to be flexible, there is no need to go running off in different directions every time someone shouts, “Squirrel!”

Your statement about “rights,” though is really where this discussion centers in my opinion. I disagree that users have no rights - they have the right to use, or not to use; to promote Blender, or to not. And, yes, that is about it. This is how it should be. Merely because Blender is free and open-source software does not enfranchise the whole planet. Creating some sort of voting system with a binding outcome on development is fraught with problems. The Blender folks have better things to do with their time than to explain to every user why their request is more complicated than they assumed.

I would think the better course is to promote community rather than democracy. If someone has a good idea, they should develop the idea and present it (on Right Click select, for instance). Get some feedback, and refine the idea. Reach out to other artists and the devs personally to promote their viewpoint. I have been following the Vasquez live streams, and cannot count the number of times that a “good idea” of mine has come up, only to find out why it is not yet a reality. Often it is a matter of “x” has to be done before “y” can happen. And of course, “w” needs to be done before “x,” ad infinitum.

Lastly, I am not saying do not do what you are doing. In fact, carry on, and thank you for participating in the Blender community.

8 Likes

i’d say if the development fund is getting enough to pay the devs with 20% surplus for unexpected situations, the blender foundation could make all the extra money after go to directly funding work on features and request voted on by the community (think like stretch goal in crowdfunding campaigns)

1 Like

FYI there are more users than developers so it’s hard to please everyone, also there is RCS with top votes system, some are already marked “in developement”.
What i think would be appropriate is if the developers go through the lists of their own areas of expertise and see which ones are feasible or not and mark them to inform the users, because there are some great ideas with less votes but probably will never see light unless more developers join.

A “pay for feature” will never work because then it becomes about money and which group of users push & lobby for certain features with their pockets.

5 Likes

Blender movies are great and Pablo Vazquez work is amazing and both are good examples of users communicating with developers of course.
As you know the Q&A portion of Blender Live Today is already making use of a democratic voting process as the most liked questions are answered first. There is rarely anyone using the feature but it’s there.

About bug fixing, if it could be filtered by votes from users i don’t see why it would be a bad thing.
That’s just another filter to choose from if it makes no difference for a developer to fix a bug over one another.
Fixing an old bug is less important than fixing a bug that annoys a thousand people.

Like developers saying “pick one of the bugs in that list of hundreds of pre-selected bugs and we will fix it next week”. Maybe it could be paper-cuts, bugs, interface changes, idk.
Just a small fun little collaboration, a bonus weekly fix thing.
The idea is just to start with something small that doesn’t require much energy.

It doesn’t matter if majority is won by a hundred thousand or by 100.
The idea is not more votes = more pressure.
It’s just that number of votes could be used to determine priority order of certain things in some cases.

I misused the word “right” my bad. What i meant is users have no way of deciding what the developers are gonna work on. They can influence but they never have the final word. I’m speaking average Joe users, not artist working privately with developers.
It doesn’t mean users would always have to be involved in the decision making process but in some case they would and when it happens democratic tools like voting/surveys/money pools could be a part of the decision making.

I totally agree with the process you described about users bringing ideas. But once a proposition was detailed and matured enough, it wouldn’t hurt to sort those based on user priority and realize them in that order if possible from a developer standpoint. .

great post! I agree totally with you.

1 Like

May I suggest you consult the current developer meeting : https://www.blendernation.com/2020/05/12/blender-developers-meeting-notes-may-11-2020/

1 Like

If you have an account on developer.blender.org to post a bugreport, you have the ability to give a token to a task.
So contrary to what you wrote, there is already a platform able to communicate community’s feeling about bugs and patches (solutions).

Just a give a token to bugreport, you want to see solved or to patch you want to see implemented.
That is a thing that developers are looking at like RCS propositions or devtalk forum threads.

5 Likes

To me, that’s what the Blendermarket or other such spaces are for.
As well, that’s what the paid apps are for.
Blender is a concept. A person’s concept. He is still spoken of.

Democracy, in this sense, is a grand ideal but suffers from what all democratic institutions suffer from: You can’t be guaranteed that the masses are informed enough to offer sound advice; Mob-rule begins to take over and the concept is lost.

The user-interface was changed because of the community’s input. Community input is the magic concept; what you speak of is control over a devvers time. I refer you back to the beginning of this note.

2 Likes

The devs fix far more than one bug per week, so the current system actually outperforms what you propose. After all, every bug in the tracker is an issue that a user reported that they want fixed.

Generally speaking the best working model for open source software is to have the leader/core team make design decisions that are only influenced by community feedback, not solely driven by them. They even have a term for this, its called having a BDFL(Benevolent Dictator for Life). This cuts down on bike shedding.

It’s important for every software to have central design focus. If open source software didn’t adopt this sort of approach then programs with this type of license would be a lot less cohesive than their commercial counterparts because some design choices users want would clash with the other choices. Some people here would probably argue that there is too much democracy in how blender is currently run, and vote to make it a clone of some commercial software.

I also need to point out that you aren’t the only one to feel this way. When they removed the old blender game engine a user was so upset, they tried to establish a german non-profit to manage a fork of blender where the users get to vote on what design changes get made:

4 Likes

You are right, the tokens are already a democratic tool.
Right now they seem to be more an indicator of appreciation but not really a direct tool used for decision making, correct me if i’m wrong.
I’ve made a search on em on the wiki page but found nothing, if you have a link to more information on how they work it would be nice.

Right now the developers, correct me if i’m wrong, have the final word as in which order features are made.
I totally get that code wise, they know better than anyone in which order things should be made.
But feature wise, How can a developer know better than a reputed professional artist what feature is most important for a specific workflow? They simply don’t but they still have take the final decision (right?).
It kinda describes that mob thing you are talking about in a way.
I might be totally wrong there since i don’t know much about who is in the decision making process other than Ton, i would really like to know more about how this.

Again, there are many ways to execute democracy. That " chaotic and uneducated mass" factor is easily fixed by using delegates.
For example, one delegate per module could be assigned to give developers a clear list of paper cuts and features to fix in order of priority. That person would represent users of that specific branch.
That list would be made from filtering through user inputs and that’s where voting/surveys and other democratic tools could be used to filter things up.
If there is no coding/design constraints, that list would determine what is what order tasks are being developed and the owner would be in charge to guide developers executing it UI/UX wise if needed.

It’s already like that if you think about it. It’s just not that organized and a lot of valuable information is loss in the process, both from user and developer side. Communication in both direction can be improved a lot. I think developers are a lot more organized than users, a big part of it is because they have procedures and tools that are more polished than the ones users have.

I totally agree, what i’m suggesting here is that the process can be improved and that democratic tools could help that purpose.

No. It Is about determining in which priority order paper cuts bug fixes and features should be implemented from a user perspective. If it makes no difference from a developer’s point of view, that order would rule. It’s also about concentrating the various user request and feedback in one place and outputting it in a way that is clear for the developers in terms of priority and design.

It’s not a black or white thing. In a backlog of 50 easy to fix paper cuts, if developers can fix 10 per week, 9 out of 10 could be fixed in whatever order developers think they should be fixed. But the remaining 1 bug to be fixed would be determined buy most votes/tokens awarded.
It’s not about 100% user-request based, but granting users a small part of the decision process to make it involving, fun, participative and more somewhere efficient.

Generally speaking yes. But sometimes it makes no difference design wise if a paper cut gets fixed before another but makes a huge difference from a user perspective. In a case like that and only in that case, users priority would be the determining factor to take a decision.

I see no conflict with some decisions being determined by users if they respect design guidelines.

Edit: clarity

Though there is a major issue with your statement generalizing bugfixes as easy projects that don’t take a lot of time. Not every bug is equal, and to fix some larger bugs properly can require a redesign of an entire module, which leads the devs. to sometimes wait until they have an entirely new and more powerful system ready to replace an outdated one (like particles vs. the upcoming particle nodes).

Here’s the thing, not every feature on a todo list can be done in any order the developer wants, there are many cases where other features and projects have to be done first, because the new feature everyone wants is fully dependent on them (asset browser ect…). Now both an important bugfix and feature that requires a redesign of related code can just be “hacked” in to get it done much faster, but all that does is create a house of cards that needs to be torn down and rewritten a few years later (because it becomes very buggy, slow, and unstable).

3 Likes