Blender Enhancement Proposals (BEPs)

General Forums Blender and CG Discussions
1

Proposal:
Blender should have something similar to Python’s Python Enhancement Proposals (PEPs) - Blender Enhancement Proposals or (BEPs).

Specification:
Pythonic. Briefly, how PEPs work:

Python is a truly community-based programming language. The community finds expression in PEP’s, or Python Enhancement Proposals. First defined in PEP 1 (they are numbered), in the year 2000, they represent a formal mechanism for getting what one wants or needs into the language.

The way it works is that if I, or you, or anyone wants to see a change in Python, it is written up in a PEP as defined in PEP 1. And then, as PEP 1 puts it, the author is responsible for getting feedback from, and building consensus in, the Python community. When that process has been deemed thorough, the PEP is then presented to the BDFL for a PEP Review. What’s the BDFL? It is the Benevolent Dictator For Life <s>, Guido van Rossum, the creator of Python (back in 1989). [replace Guido with Ton]

The possible paths of the status of PEPs are as follows:

More on PEPs (Python PEP1):

Motivation:
As I follow the links, there’s so many ways to submit a proposal/suggest an idea: you can email the devs, post to the mailing list, post to the forums, IRC chat, wiki TODO list, blenderstorm, stackexchange, blendernation, blendernetwork, dev blogs, personal blogs, etc. - it’s all over the place.

For example, eventually, these threads get so long, you can’t tell the original proposals from the comments (is this the reason for stackoverflow?). I see so many great ideas but they can’t be seen by the right people i.e. devs, community leaders, etc. Nobody has time to sift through 50 pages of 50 threads.

Rationale:
Currently existing solutions:

  • Blenderstorm - disorganized and poorly written, they aren’t taken seriously. They’re also somewhat disjoined from the Blender community. If the BEPs were created, they should be hosted by blender or blenderartists. For example, the bug tracker is not hosted on another site or disjoined, as it is critical to development. For an open-source project, isn’t community input just as critical? When I say community input, I mean more so useful ideas than general banter.
  • Forums, mailing lists - disorganized, often get cluttered with flamewars, tangents, etc.
  • Wikis - IMHO inappropriate for suggestions - better for cataloging common knowledge than developing it.

The PEPs are really quite elegant and democratic now that I think about it. They give people in the community a stronger voice than creating a thread or the mailing list, etc where the idea will get lost amidst the noise, just as this proposal might…

What I’m proposing is to organize that flurry of ideas into a more meaningful way. Those existing channels will always exist but there should be a central channel that allows information to flow smoothly between developers and users, and not get contaminated by other objects.

This helps reduce redundancy from the user’s POV, as they don’t need to search all over the place to see if their idea exists. It’ll also allow them to improve and think through their ideas by being exposed to other people’s ideas.

From the developer’s POV (using my imagination), as a result of the user benefits, they don’t have to go through so many trivial proposals. Likewise, they can see all the ideas in one place and communicate with each other more efficiently.

2

About Bf-funboard

Discussions on Blender functionality, at the end-user level.

The goal is to further organize a ‘functionality board’ and to assist and inspire Blender developers in coding projects.

http://lists.blender.org/pipermail/bf-funboard/

3

I think the mailing lists are no different than the forums since they’re not strictly formalized, categorized and indexed how the PEPs are.

4

A very similar proposal to this was recently made on bf-funboard.

http://lists.blender.org/pipermail/bf-funboard/2013-September/005576.html

The proposal was to put in place a formal process for decision making about how Blender should behave that is separate from the decision making process on implementation details. I think both of these are very good ideas and could help address some of the paralysis and bureaucracy that outside developers must face when trying to make contributions.

5

The other key aspect is the process. From that proposal:

I agree with many things you’re saying, and I like the questions in your
document. I agree there is no lack of user-feedback, and that
committers/code-review is a bottleneck. I agree many suggestions don’t
consider all the factors, and I agree that feedback noise sometimes makes
it hard to notice the coherent proposals.

However, based on what I’ve seen, I believe there is more of a process
challenge than a manpower challenge.

As a result, I don’t think strictly adding more committers or identifying
module teams (which has sort-of been done) will improve the situation
greatly without also making process changes. Fortunatly, I think process
improvement will dramatically change things. You can see this a bit in the
success of GSOC projects, because they have a better process with more
up-front buy-in and approval. However, let me explain in more detail why I
say this.

Blender kind of already has the suggestion box, but it’s just messy. Fortunately, Python has already sorted this out for us! And I believe their implementation works well, witness Python’s dominance, growth, and community especially.

I think BEPs are the answer to that challenge.

6

+1
I miss some dedicated place for feature requests…

7

I think the problem is that the people who would submit these BEPs aren’t necessarily the same people who would implement them so you’d still have the same problem as today: there simply isn’t enough coding hours in the day for everyone to have their pet feature implemented by some active coder.

PEPs are good for python because, as a formal language, it is very resistant to change. Small changes have large impacts on production code – just look at all the complaints when some small thing is changed in bpy and multiply by <some large number> to get an idea on how this would go down in the python community.

8

Ya, a stable Python API would be nice…

So if I read it correctly, you’re implying that Blender is not very resistant to change? Then methinks this proposal process should help organize all these proposed changes better?

The way I see it is, the BEPs filter the ideas coming from the forums and whatnot so we can get the more widely-impacting changes. You could say the most popular changes will naturally surface but I think more is required.

Each PEP [or BEP] must have a champion – someone who writes the PEP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The PEP champion (a.k.a. Author) should first attempt to ascertain whether the idea is PEP-able. Posting to the comp.lang.python newsgroup (a.k.a. [email protected] mailing list) or the python-ideas mailing list is the best way to go about this. [or BlenderArtists forums]

Vetting an idea publicly before going as far as writing a PEP is meant to save the potential author time. Many ideas have been brought forward for changing Python that have been rejected for various reasons. Asking the Python community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Python is used.

For example, PLyczkowski over in the Blender UI and Mockups Requested thread created a well-thought out proposal rather than just a picture without details, but it won’t easily be noticed bc it’s buried deep.

In the end, it won’t solve the problem completely but I think it’ll make things it a little cleaner and a little easier.

FWIW, the fact that Python retains all the PEPs make it kind of like a community/user repository or something.

9

To be honest, I wish more people would start up google docs for their point of interest, whether this is the UI or any of the features in Blender(The Gamedev spreadsheet is another excellent example). It makes it a lot easier to take them seriously than a random vague complaint on a forum. It also quickly helps getting people up to date, such as people new to the subject as well as potential developers.

10

Check out the bf-funboard post, and following discussion, I linked to earlier. The proposal was made by an external developer and was, at least in part, born out of frustration in the current process of getting his UI changes accepted in to Blender.

Right now the signal to noise ratio is very low and setting up a formal proposal process would make it easier for external developers to contribute. Before writing a line of code there would be a central place to go and get a decision that:

“This is a good idea and if implemented in an acceptable way will be accepted in trunk.”

or

“This is a bad idea, because …, and will not be accepted in trunk.”

By separating the high level UI design phase from the nitty gritty implementation design phase developers are less likely to waste time on changes that will never be accepted for conceptual or philosophical reasons.

11

In order for this to work, you’re going to need to get buy-in from Blender developers. History indicates that’s not likely to happen (hint: Blenderstorm was written by a Blender developer).

12

Getting something done is really a political process. Until “someone” says “feature X has to be implemented” (note has not should be) that X will remain in limbo forever.

Remember the story of ngons: talking about them was nearly a bannable crime on Blender-related forums (with lots of “explanations” about why they were bad, explanation which stank of grapes-are-sour rationalizations) and then… all of a sudden… “somebody” said the magic has/must… and BMesh was cleaned up and went into trunk.

No BEP can change this.

13

While there were certainly people who weren’t in favor of ngons, saying it showed up all of the sudden is very inaccurate. Bmesh was the 3rd incarnation of ngon support in Blender and it took nearly 2 years to develop… much of which was done very publicly.

14

Exactly, any initiative like this needs to be spearheaded by the Blender Foundation. Until then it doesn’t matter how many videos are made, mockups are constructed, or posts are written for every 1 good idea that gets picked up 10 more will be buried under a mountain of unorganized and uncataloged noise.

Blender is the only opensource (or commercial) project I’ve ever had any involvment with that doesn’t keep track of feature requests and I honestly can’t imagine a good reason why that is.

15

I would accept BEP’s if the person proposing would also implement the features themselves (or at the very least co-author with a developer).

Otherwise this just ends up being more users shouting into the wind, and time wasted to review something that nobody has time to implement.

16

This is why: http://blender.stackexchange.com/questions/1190/best-place-to-put-feature-requests/1211#1211

17

I don’t understand this position. It may make sense for something like the Linux kernel (Ok, there’s one opensource project that doesn’t track feature requests) but ignoring the needs of your users seems like an awfully strange approach for a user facing application like Blender.

18

That is exactly why a formal process for feature requests, BEP’s, whatever you want to call them is needed. There is absolutely no reason developers should be getting personal emails, IRC requests, etc. Separate the feature design discussion from the implementation discussion and developers can largely ignore the former if they so desire. Of course some design is limited by implementation details so that isn’t entirely possible but the separation would make it easier for people with different skillsets to contribute. Make the process easier and you will attract more contributers.

19

Hmm, BEPs == Google SOCs? It would be like every season is SOC :p. That doesn’t sound like a bad idea. It’ll help usher in new developers. Although, it really depends on whether the developers have the time and motivation.

We all know the amount of developers and developer time is limited. How does the Blender Foundation/Development decide what is a priority and what isn’t? Or how does Ton decide? Of course, being volunteer developers, there is no superior directly telling you what to do other than the BDFL. So naturally developers are more likely to advance features that cater to their needs. And that is kind of how open-source works, somehow that “selfishness” is effective and produces a public benefit.

I think more democracy (idk what word to use) is required as a program gets larger. It’s not as crucial when programs are smaller with less features and less users, but as programs grow and expand, priorities become much more apparent due to the increasing chaos. I might go so far as to say the development team takes on a larger role by responding to the community. This is especially so, when the growth of the development team does not match pace with the feature set. Without regarding the community, I think development and attracting new users will be slow. For example, the infamous Blender UI, RMB select, etc. The userbase is your focus group, your PR, etc. And of course, a full neglect will cause a fork but Blender is the only one of its kind so that means users will only return to the proprietary solutions.

Initially, you start the program for your own benefit but as more people find it useful, their input becomes increasingly important. Eventually, a project grows so large that there’s not enough resources to allow people to do their own thing. At that point, more organization is needed, less something gets neglected. Now, this kind of runs contrary to what I stated in the previous paragraph, because now you have a much stronger external force that directs what you’re doing rather than doing it purely out of self-benefit. Although, I think having to respond to a community is better than having to respond to a bunch of corporate executives :stuck_out_tongue: So there is a price paid with open-source but it is a much better price than closed-source solutions.

Community is the main advantage of open-source. Thus, it should always be taken full advantage of. If the developer’s decisions are not heavily influenced by the community, something is wrong. Essentially, community influence in the decision making is proportional to the size of the program and number of developers (within the range of the userbase). I feel an urge to make graphs… :smiley:

The BEPs really are a political process just as they are a way of organizing ideas. So yes, without the dev-side implementing the process, this will just be another waste of time.

20

Edit: There is of course value in some more formalized design process (in certain cases), feel free to propose this on the bf-committers mailing list.

However my guess is we would continue to have small self-selecting teams of users & devs who work together and focus on areas to improve.