Functionality board

[ton]

With the increasing amount of people committing code, and with the lessons learnt from the past release, I think we're ready to add another organizational level here. That concept is:

the Functionality Board (FuBo)

with as main goals:

- advise & decide on functionality issues
- come with proposals (functional docs) for new projects
- and of course: getting more users involved with coding projects

some practical jobs they can do are:

- reviewing feature requests at the Tracker (projects.blender.org)
- providing 'buddies' for coder projects, to help reviewing test versions, provide demo examples, help with a release (docs, tutorials, artwork)
- make decisions on the very basal interface issues, like menu wording, hotkey assignments, wire frame colors, etc.
- provide feedback & approval on software projects that affect the end-user of Blender.

The decision process can be organized as follows:

- the FuBo gets a similar structure as the current bf-blender coders project; with three admins, and a larger group of members
- the admins can decide to allow or reject members
- the three admins have the right to force decisions, but they try to find maximum consensus among the members
- on functionality issues, the FuBo *and* the coders (admins) have to agree.

I will personally facilitate the process. Make sure communication goes well, using maillists, irc meetings, making notes, etc. When no agreement among the teams can be reached I reserve the right to force decisions. In this 'presidential' role I can also put down a veto, but won't do that easily.

This is still a proposal, part of a discussion that went on after reviewing the past release. Right now, the most urgent thing is to have an official platform to get feedback from. Daily practice then will learn us how cooperation will work best.

The 'democracy' issue plays here as well... we could for example organize elections for the FuBo. My proposal is not to do that (yet). I like to get some feedback on this topic first. With sufficient positive reactions, people here can propose candidates (or themselves!). I then will appoint the three admins myself, and let them find the members. After a 3-6 month period, we then can evaluate it all.

-Ton-

[jesterKing]

Hmm, so at this point it looks like there will be the 'traditional' three levels in design documentation:

- requirement specification

this will be probably the main feature list with a quite general description of them and Blender as a whole

- functional specification

More precise specification, API issues and such.


and
- design specification

The 'in-code' documentation (or actually, the document that is written just prior to actual coding, but in practice it is written while coding ) Doxygen can be there a powerful tool.

In my opinion this is a good approach, even though we are talking about an Open Source effort. Good organisation is vital for ever-improving development.

[ton]

I prefer to define 'functional specification' at end-user level. And since the end-user is an artist, and not a coder, this is entirely user-interface based. Unless of course we describe python or plugins... so better said; a 'functional specification' can straight move to a user manual.

The 'technical specification' then is at coders level. With dependencies, general module structure, the interfaces for modules/libraries.

In the traditional s.w development process a third level then could be the actual code design itself. Describing all data, functions calls, etc.

We shouldn't go too far (yet) in this approach, it has to be fun too! But with so many people working at blender, we have to formalize more now...

[B@rt]

How do you 'decide' anything in an open source project? It seems to me that the only decisions that can be made are afterwards:

- is this feature useful enough to be included in the official sourcetree?
- is this new stuff coded well enough to be included in the official sourcetree?
- will this break other functionality?
- was it a good idea to drink three bottles of Coke?

How would you 'enforce' the decisions of the FuBo? If anyone is motivated enough to write a new Blender feature, I'm sure that he'll do it anyway, regardless of 'decisions'.

What I would do is this:

- keep well-documented wishlist. Write down what users request, discuss good 'clean' implementations and write down the name of people who are currently working on this (to prevent people from doing the same thing twice)
- create a clear policy on what will and what will not be merged into the official releases
- put your energy into creation, not in management processes. Did I mention that I have a particular dislike for managers?

Have fun,

B@rt

[matt_e]

- is this feature useful enough to be included in the official sourcetree?
- is this new stuff coded well enough to be included in the official sourcetree?
- will this break other functionality?
- was it a good idea to drink three bottles of Coke?

I think this is what Ton has in mind, (perhaps with the additions of some other questions too), but also bringing these sorts of decisions out for users to agree on too, rather than coders only. Since the users will be the ones actually using the software, it makes sense for them to have some input in how things eventuate. By forming functionality specifications, in effect such a proposed board would be creating policy for what and what not would be included, as you mentioned.

From what I can tell, the idea isn't to make an 'us vs them' situation where a board would be allowing/disallowing/vetoing features from coders, rather the idea would be to get users working more closely with coders and getting everyone involved in the development process..

[B@rt]

That's not how I read the post - I hope you're right. But still, it's the coders who are doing all the work in their free time. To put it bluntly: why should they care about what a FuBo or a group of users decide? Personally (but that might be just me), I would just do whatever I like to do and if that matches the existing idea: cool; if not: too bad - do it better yourself.

The proposed model would work in a formal IT/CS company. However, this is a group of volunteers who do not need to take orders from anyone. The best you can do (I think) is to provide cool ideas for them that would guarantee the praise of the users.

I've seen this happen in the Blender DocBoard group: Ton and some publisher would like us to work towards a new published Blender Manual. While this is a very good goal, there have been exactly *zero* replies to that proposal. The contributors have other priorities...

Have fun,

B@rt

[ton]

How do you 'decide' anything in an open source project? It seems to me that the only decisions that can be made are afterwards:

- is this feature useful enough to be included in the official sourcetree?
- is this new stuff coded well enough to be included in the official sourcetree?
- will this break other functionality?
- was it a good idea to drink three bottles of Coke?

It was not my idea to formalize *all* development. A lot of additions to blender can just be done with a coder spontaneously committing something he is enthusiast about.

Nevertheless, in the past months we've had difficulties in making basal simple decisions... from menus to assigning a hotkey, a wire frame color, etc. It speeds up development a lot when a group of people can just investigate such issues, and come with proposals.

So how do you 'decide' in an open source project? The truth was that it still all goes via my desk... something I can't do all by myself. I also would prefer focussing more at 'creation' and less at 'managing'!

We also noticed that the current coders team has to few real 'power users' among them, and we miss having regular feedback from them.
So I see it as a way for non-coders to contribute to the open source project as well.

What I would do is this:

- keep well-documented wishlist. Write down what users request, discuss good 'clean' implementations and write down the name of people who are currently working on this (to prevent people from doing the same thing twice)
- create a clear policy on what will and what will not be merged into the official releases

That's what I propose to organize here. Don't get confused with the 'functionality board' we had at NaN. I think we are in a completely different situation here.
Maybe i should have choosen a different name, like 'user feedback panel' or so... nothing scary, just a means to make it all going a tad more efficient, documented & tested!

[ton]

and to make it explicitely clear; it is not the purpose that a FuBo is going tell coders what to do!

The need is for the opposite, coding projects need help! We need specs & feedback on important issues.

Maybe I have formalized the decision process too much. Just wanted to put down clear guidelines...

[B@rt]

Guidelines are ok!

B@rt

PS: You were right - I *did* think that it would be similar to NaN's functional requirements board. I was quite surprised to see it since it never worked there, either

[Money_YaY!]

Are you going to send us to war ? El preseden'tay

It is good and basic.
And for "just " BF blender it is fine. That is your blender.

But Tuhopuu needs to be away from that way of thinking.
Though things for both partys are getting confusing now.

Tuhopuu was to be the Meca of new features. Now there is yet
another tree with out being a tree. The Audio SeQ. And it was never
placed in the Tuhopuu tree. Plus reading yesterdays IRC bit. Somebody
comented that he will start incorperating the BF tree into Tuhopuu. Wa?
Was'nt Tuhopuu supose to be the Tree that BF pulls from?

I'm just a bit confused. But to keep team moral up do not wait so long
again to release another point upgrade. this is open source , upgrades
should come in all the time. not every month.

As for Auqa . Ha ! I do not think that is major. Lightwave does not have Aqua it runs fine, it would be nice but hey ! Why not build yet another
tree.

[hawk]

Please remember that Freedom is a very formal concept!
I like Ton's idea, and it is just what I were looking forward to.
I'm not a power coder, nor a power user.
Most of blender's users are like me.
And I would REALLY like to be able to interface myself with people more blender experienced than C++ experienced.
I like alot what coders are doing (I always read the ML) but I cannot interfere with them just ask trivial questions.
Ton is great, but freetime is a limited resource.
I think that having a layer of semi-coders between coders and users would be like having a helpdesk for both categories.
They would have a BIG job to do!

[beatabix]

Somebody comented that he will start incorperating the BF tree into Tuhopuu. Wa? Was'nt Tuhopuu supose to be the Tree that BF pulls from?

Tuhopuu is supposed to be bleeding edge, right?
Well, how is it going to achieve that if it isn't even up to date with the current BF tree?

BF advances too, so Tuhopuu has to grow from current BF sources.
makes sense, doesn't it?

later
BEAT

[ton]

I am very happy with Tuhopuu of course. But Tuhopuu is a free and independent project, and not meant as 'official' try-out space for bf-blender projects. If other groups of coders would like their own experimental tree, please go ahead; I will be happy to add that to the projects site!

For quite obvious reasons, we try to build a single official release, and with people getting more familiar with the code, they can directly work at the main blender tree itself as well. This also with the purpose to have intermediate releases out.
And of course, what feature will make it in the official release or not, is something we need feedback on, and that's the whole origin of the functionality board concept.

[Bischofftep]

Count me in!

As a heavy Blender user and an amateur coder I'm quite happy to contribute, especially on my chosen platform (OS X).

What's the next step?

-Bischofftep

[ton]

Next step will be posting something more official, as an article at the frontpage. With timeline etc.

But, I still would prefer some feedback.

Also: just nominate others. I guess quite some here consider themself good candidates but still hide in a corner.