Functionality board

General discussion about the development of the open source Blender

Moderators: jesterKing, stiv

cessen
Posts: 109
Joined: Tue Oct 15, 2002 11:43 pm

Post by cessen »

Assuming that this is specific to bf-blender, I think it's a good idea.

I would love to be a member of the FuBo, but I don't really want to be an admin (not that anyone was considering me, anyway :-)).

leinad13
Posts: 192
Joined: Wed Oct 16, 2002 5:35 pm

Post by leinad13 »

Ton i think its a good idea, i would certainly like to get involved. But i think you should post on Elysiun, so that we get some of the main artists who may never these forums, becasue they think it is for coders. As you said what you have in mind is for the artists and so we need to get artists on the team. Any disagree with that?
-------------
Over to you boffins

L!13

ton
Site Admin
Posts: 350
Joined: Wed Oct 16, 2002 12:13 am
Contact:

Post by ton »

sure i agree with that... just busy here with coders stuff now... and its about 35 degrees C inside here!

thorax
Posts: 320
Joined: Sun Oct 27, 2002 6:45 am
Contact:

Re: but...

Post by thorax »

B@rt wrote: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
Its not possible to enforce decisions, but it is possible to inform them..
That's really what the design docs should be about.. Uninformed
development results in developments that conflict with each other..
Like what if you have 3 guys making the same change to the sources,
what do you do? Who wins? The best one? Why not combine them
and turn it into a learning experience for the each..

thorax
Posts: 320
Joined: Sun Oct 27, 2002 6:45 am
Contact:

Re: Functionality board

Post by thorax »

ton wrote: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.
Whe you say user you mean the ones who can't code.. I think of developers as users too.. In fact users can exist at many different levels.. Its just that the more creative ideas tend to come at the higher-levels (where the human is more distant from the processes that work within their programs).. Higher-level in this case is not necessarily better, you do need the coder/users and code-design users to help in clarifying the processes.. I don't believe in the idea that real coders can talk in lingo that would be impossible to understand by a user, some understand well
others are reserved coders (such as I) which tend to avoid highly-detailed
coding until a design process has developed (you can't get what you want 'til you know what you want - to steal from Joe Jackson).
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.
You can't force anything anymore Ton.. Just as anyone can take the blender sources and do parallel efforts.. We need to think about informing
rather and more trustworkthy relationships where nobody is being leveraged to do something they don't want to or else.. But we will need to
have a voting system that ends at the admin's in the case of a tie, not the other way around.. I think there is not much control in such cases..
At best the coders that stick to the design and the ones that work in tension to the design, the result should be productive as eventually
the design and the users benefit from the competition.

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. :-)
Ton I would at best let you be on the board of advisors but I'm not sure about a presidential role. I doubt linus gets this much respect for doing Linux these days.. We need to be more of a committee of designers
and use the voting system to make or break decisions, but group think
as you know from your design courses back in school is not very useful
and results in a lot of conflicts.. But the process of arriving at the design
docs will go about by having those with more experience help out in informing the others.. I would not try to predict the cases where
you would need to enforce anything, but maybe I'm assuming the coder/user base is smarter than the average non-coder user or non-designer coder. Designers become such out of frustration of bad designs, it becomes a nervous mentality that it can be done better, but it helps more to be a designer-user-coder as you are, and I think we would
regard you as one of the greats, and 4 out of 5 my alternate personalities would agree as well (8^) .

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-
Focus is important.. But I believe in the idea that deomcracy int he day and age of computers where everyone has a say and polls are performed frequently within minutes, it should be possible to make decisions in a
non two party type system (ala american), that it is possible to have
N-ary party voting and agreement.. But there is the risk that some
individuals in the blender group could be conspiring vendors in the interest of sabotaging this great thing we call blender, its not a
bad thing to consider especially if you see blender as a problem
with being able to compete in 3D apps.. I'm sure blender is on the radars
of Softimage, Alias/Wavefront, NewTek, etc.. May explain for the high-read counts in the forum with few replies from guys like me and dreamerv3, broken, money_yay, etc.. How should I interpret this,
are we the only ones with a voice or is there a great multitude of conspirators?

Note most of OMG committees are made up of vendors which are there because they wish to sabotage the standards in hopes that nothing
is ever resolved.. I know this because I've talked with ones who have been involved int he process a lot.. The day you fail to be during a
comittee discussion is the day the standard gets screwed out the wazoo and everyone pays for it, except the one who was able to steer the standard into the creek (which likely is not using the standard anyhow).
The only way to develop a CORBA spec these days is called "Fasttrack"
and what Eskil is demonstrating, where you implement it, prove it can be done, then the scoffing secretive saboteurs cry in agony secretely
because they can't scoff at this.. However if you can scoff, scoff with a
reason, and maybe you can discern yourself from the saboteur.
If you can sabotage a design standard without being caught, I say that's
and art in itself, but I doubt it will last..

Think think think..
Design is about deep thinking and eliminating as much as
possible hidden details, general assumptions and easygoing
approaches.. Design is about detail backed up with reasons, if
there is no reason, its a feeling and it should come out in discussion..
True design is based in experience and reason, not political relationships
and group-think..

thorax
Posts: 320
Joined: Sun Oct 27, 2002 6:45 am
Contact:

Re: Specification writers

Post by thorax »

jesterKing wrote: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
reuirement specification might also involve thoughts about the implementation as users are not individuals in a vacuum, there will
be coders at this level and they will have defined ideas about how to
do things they see..

The big problem in businesses is to turn to their focus groups than to turn to their coders when developing a product.. It should be both..
And maybe an interaction between the requirements and functional
specifications is needed.. This coders could inform the users on
certain relationships, but in the users you have designer-users, coder-users, and some with all levels of experience.. Some coders tend to
be rather poor designers because they spend a lot of time looking at nuts-and-bolts and may not ever use the stuff they make or may not be able to conceive of the audience (their market).. What made UNIX unique
is its development was done by its users because its users were
scientists, educators and programmers, that's why it was successful..
General users are pretty poor at making design decisions but they
shouldn't be informed of their mistakes (it makes for less openess)
and I would be the one to say that knowing my record 8| .


- functional specification

More precise specification, API issues and such.
informed by users and developers who are users, and designers
who are users too.. I hope developers who get involved are also users,
it doesn't make sense if a developer is involved that has no interest or
use of blender..


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.
Yes the bible of design.. ITs what makes or breaks decisions..
But as I said there will always bee that external tension of coders who
wish to encourage a design concept that was rules out in the design..

Think of this as informing the new developers and a way for
the committed developers to direct themselves and keep
oriented the development. Its the blueprint..

Now its possibel to take these docs and create
source files with comments, we then code things in reference
(this is like localizing complexity, the design docs and the
code are there together, no questions left unanswered.)
But sometimes while coding up the stuff you must document what you did
this is not the same thing as a design doc, its like intentional
informing on the spot, to say this is not in the design but this be
my plea for adding this feature because blah blah blah.. That's
what commenting code is about, its more to help those afterward,
but this enters in to the idea I had about having code fixes make
it into the comments in the code.. The coders who think comments
break the look of the code can always run the code through a filter
or use an IDE that allows one to compact the comments.. There is
no argument against commenting code, there is volumes of arguments against not doing it.. And this is not abotu micromanagement, its more
about being kind to yoruself and others, what will you know two years from now when you revisit the code.. If you commented it, you
will say "oh yeah, that's it", if not, you better have a damn good memory..


All extra code that did not follow the design will
be realized in the post-mortem.. Think of this as "mistakes we wish
not to make later when the code is updated" and things we
did right that we should praise ones reponsible for and encourage the relationship by making them more reposnible parties (the real voting could come out in the post-mortem).. But its not about finger pointing, more just about what are unproductive design processes
and be able to recognize them the next time around..

thorax
Posts: 320
Joined: Sun Oct 27, 2002 6:45 am
Contact:

Post by thorax »

B@rt wrote: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.
You should be free.. I should be the one to talk considering I jump
on Eskil and Ton.. Its really an act of being left out of a design process..
Coders are used to it, the machines complain to them all the time..
A design process is about making the coding process fun and easy and
minimizing the amount of frustration as well as the complaints..

But coding it up is the ultimate free speech, but the ones who will
most likely resonate with yoru ideas will be those who understand
and feel are affected by it.. General users with no programming
background need others to help them understand efforts like
Eskil's.. I'm not the best for this.. But programmers tend not to
be good with people in general. Its because they work in closed room with nothing but a machine.. A machine will do what its told,
but its tough to tell people to do what you want them..

The best thing to do is write to inform and code to inform..
Its easy to force either down everyones throats without letting
them say anything.. I just tend to respond much more and I
think I try to cut it down.. Just hate to leave anything to
common sense as that is an assumption about other's sense of
what is common.. Especially since we are worlds apart what can I know about yoru culture or world view and what can you know about mine..
It helps to communciate now than riot about it later..
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
Well I think a manual is hard to do because it requires a lot of writing and revision.. Maybe we should rethink the process. Say get everyone a copy
of camstudio and realvideo helix, we would then record ourselves
on the desktop showing our ideas, drawing them out, videotaping
from a camcorder, whatever.. Then upload this to the doc server..
We can listen, review, its easier to listen than to read anyhow..
Then we could maybe make a document from that, maybe leave it as videos? What do you think?

thorax
Posts: 320
Joined: Sun Oct 27, 2002 6:45 am
Contact:

Post by thorax »

Money_YaY! wrote: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?
Just to go to say, I'm missing "Enter the Dragon" which is on Telemundo (spanish channels have cool movies, wonder why english speaking channels aren't that cool).. Netherland's TV is pretty cool too..

Tuhopuu I think was a experiement.. Maybe a exploratory research
of sorts.. I think Ton knew from the beginning there needed to be a
re-design stage and at the very least involves discussion..
But its about taking action.. I'm all talk ain't I.. Well its because I'm render rangling right now, so not much to do code wise (that's and excuse, *snicker*)..
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.
Cut it out with the gimme gimme gimme attitude, that's not moral building?! Ah I should be one to flick the speck from your eye and the
log in my own.. Okay sorry.. But to get what we want probably
would involve some thinking about the design.. There is a lot of
hype about open source but its hard to define what it is or what is a property of open source, in general its a means to communicate or
control, but not about micromanaging.. But I can say what I want,
so can you..

Opensoruce is about what you can do out of the confines of time and space, and its about doing what can be done when it can, not as you expect.. Which makes making a design docs hard as its not the
formal process of a commercial effort because as everyone has said to me its a volunteer thing.. So I guess the design docs are more of
a informing thing.. And that's good, programmers like to know this
stuff, and like it even more when its formal and detailed!! To get the really good coders in you need good design docs and
a organized approach.. You have that you can really bring them in..
I guarantee it !!

Just try it sometime.. First try to hack something together
major, it takes years.. Then after than go do a design doc and
then code up something, I bet the time it takes you to the design and
code, you could have done it five times over in the time it took
to hack something without forethought.. Open source is not a auto-design and code trick, its vouched for by press and journalists which don't
know didley about how it works.. Sometimes open source is developed by corporations that see open source as a cheaper solution than
designing their own.. So to clear up the assumption that is the usual
of a thousand random coders will erect the best app int he world, it won't happen unless there is a lot paid attention to design.. ITs got to happen..

dreamerv3
Posts: 119
Joined: Wed Oct 16, 2002 10:30 am

Post by dreamerv3 »

Thorax: Ok enoguh about how design is so important, I don't think there is a single person (well maybe one or two) who would disagree and say that design should come after the codeing implementation phase. Most people agree about the importance of design, how about we get down to it. Start high level and work down...

Now lets talk design, if or better put WHEN we go modular, what basic structure for the application would you recommend?

In order of center --> out via nested () the kernel being the center what do you think of this?


(ui skin(ui interface hooks(tools --> logic (abstracted data(Kernel))display and rendering subsystem)command line console)

I've left out the plug in and other parts, I've got to draw this up in Dia or the Openoffice "Draw".

Let talk sensible, fast, and modular design.

ton
Site Admin
Posts: 350
Joined: Wed Oct 16, 2002 12:13 am
Contact:

Post by ton »

Hrms. Confusing feedback and with mixed results... i would prefer if posters stay on topic, and be as brief as possible in replies.

My only aim was to find a group of users (coders, artists) who like to help out in spending time on specs, feature requests and improvements.

I'll put the idea back on the drawing board.

OTO
Posts: 60
Joined: Wed Oct 16, 2002 8:51 pm
Contact:

Post by OTO »

And good luck to you Ton to manage all these "crazy" guys!! :)

Anyway, they participate, me too i'll be glad to participate as an...euh...artist??!!

Bye
António

thorax
Posts: 320
Joined: Sun Oct 27, 2002 6:45 am
Contact:

Post by thorax »

dreamerv3 wrote:Thorax: Ok enoguh about how design is so important, I don't think there is a single person (well maybe one or two) who would disagree and say that design should come after the codeing implementation phase. Most people agree about the importance of design, how about we get down to it. Start high level and work down...

Now lets talk design, if or better put WHEN we go modular, what basic structure for the application would you recommend?

In order of center --> out via nested () the kernel being the center what do you think of this?


(ui skin(ui interface hooks(tools --> logic (abstracted data(Kernel))display and rendering subsystem)command line console)

I've left out the plug in and other parts, I've got to draw this up in Dia or the Openoffice "Draw".

Let talk sensible, fast, and modular design.
That would be good, I was going to suggest ArgoUML, it looked kinda
like a Rational Rose clone, but it seems like its still got some issues (it doesn't crash, just seems to not be very well designed, boy they must really need a CASE tool)..

OpenOffice would be good, I've got a copy of it laying around here somewhere.. I can get it installed.. We can use UML notation
even without a UML case tool, but it would be nice to pass
graphs around with those tools.. We could also use blender
(just get a ortho view, make up some diagrams, parent some
text, copy, etc..). Can even reference text int he text editor..

thorax
Posts: 320
Joined: Sun Oct 27, 2002 6:45 am
Contact:

Post by thorax »

ton wrote:Hrms. Confusing feedback and with mixed results... i would prefer if posters stay on topic, and be as brief as possible in replies.

My only aim was to find a group of users (coders, artists) who like to help out in spending time on specs, feature requests and improvements.

I'll put the idea back on the drawing board.
Well I'm going to help, but I don't think a hiearchy of developers
is best, not sure if anyone can commit like that, but we can use
voting on different levels to determine what stays or goes in the design,
can't necessarily select what goes or stays in the code, that will
be determined by what the users think, but I think the design
needs to be there so coders coming in won't be totally lost, and
will know what to shoot for.

joeri
Posts: 96
Joined: Fri Jan 10, 2003 6:41 pm
Contact:

Post by joeri »

Thorax: I did not read any of your stuff.
Way to much text to be possibly interresting.

-Joeri

IoN_PuLse
Posts: 212
Joined: Wed Oct 16, 2002 6:05 am
Location: Canada, BC
Contact:

Post by IoN_PuLse »

joeri wrote:Thorax: I did not read any of your stuff.
Way to much text to be possibly interresting.

-Joeri
Amen to that.

Post Reply