The future policy for dealing with user feedback?

matt_e · Post by **matt_e** » Wed Jun 11, 2003 5:34 am

Jamesk, personally I don't see those steps as much of an improvement on the existing situation - indeed you mention in step C, that it's just the same as before (which is what we are trying to improve on). Having a situation where coders get no say in the matter of the fuctionality discussions is just as bad as the current situation where artists get no say.

The crux of it all is that we don't want artists to be off on their own saying "this is what we want, now do it" since it creates an us vs them kind of situation and is inflexible to the realities of what's possible, and what people are actually willing to code. It would be much better in a more inclusive situation where people can work and discuss things together. Not to mention the thought of trying to manage a beaurocratic structure like artists -> 'BUIG' -> FuBo -> coders mailing lists -> coders gives me shivers down my spine

I think just having a functionality board which is pretty similat to what you were mentioning in that step A, with strict limits forbidding technical discussions - keeping the focus to Blender and its use would be best. The FuBo isn't proposed be in the "coders' domain" - it's supposed to be separate from technical development discussions, yet including ideas from all people.

Having a one way process like you described would also take away a major purpose of a FuBo (or whatever you want to call it) - that is a resource for coders to help figure out how to implement their ideas and new features. It will be helpful for such a group to be used as a research resource that coders can bounce ideas off for how new features can fit into blender. This is what I mean about a two-way process and working together. Artists certainly don't have a monopoly on new feature ideas, and neither do coders. It's also pointless just submitting feature requests, if nobody wants to code them. That's why we need more collaboration in a kind of 'reserved space' where users don't have to get caught up in the technical stuff, just discuss the functionality.

Jamesk · Post by **Jamesk** » Wed Jun 11, 2003 9:42 am

broken wrote:Not to mention the thought of trying to manage a beaurocratic structure like artists -> 'BUIG' -> FuBo -> coders mailing lists -> coders gives me shivers down my spine

Yeah, it does sound quite horrible as I think closer about it.

Well, I'm sure everything will work out fine in the end no matter what.

thorax · Post by **thorax** » Wed Jun 11, 2003 10:32 am

broken wrote:Jamesk, personally I don't see those steps as much of an improvement on the existing situation - indeed you mention in step C, that it's just the same as before (which is what we are trying to improve on). Having a situation where coders get no say in the matter of the fuctionality discussions is just as bad as the current situation where artists get no say.

I agree.. But I think its where people have no say that is unfair..

The crux of it all is that we don't want artists to be off on their own saying "this is what we want, now do it" since it creates an us vs them kind of situation and is inflexible to the realities of what's possible

(edited later) Yeah its not good to have the users off in their corner expecting features, that can't happen since this is open source, its not NaN anymore.. But we can define what we want and determine a structure that would allow for what we want.. And I see the coders as just extended users that can actually make changes to the source. I'm asking that everyone get back and combine feature requests and to determine what structure would support these ideas

I understand that but its due to some perceived difference or
a feeling that some are untrustworthy, for whatever reason its motivated by a need to be careful in some way that produces the us versus them mentality. That's okay, its just not good to ignore the other side
when they come to express themselves..

and what people are actually willing to code. It would be much better in a more inclusive situation where people can work and discuss things together. Not to mention the thought of trying to manage a beaurocratic structure like artists -> 'BUIG' -> FuBo -> coders mailing lists -> coders gives me shivers down my spine

It will be more like

Artists<--->Designers<---->....<---->coders ..

Coders are being defined I assume as those who are currently coding rather than those who can code. Its a subtle difference in the "Lazy Coder gene".. LazyCoder = Designer..

I think just having a functionality board which is pretty similat to what you were mentioning in that step A, with strict limits forbidding technical discussions - keeping the focus to Blender and its use would be best. The FuBo isn't proposed be in the "coders' domain" - it's supposed to be separate from technical development discussions, yet including ideas from all people.

Well in Computer Science, the way its taught, its stressed to
keep implementation concerns for last.. Implementation usually means
any freedoms we have of choice in the structure that shouldn't constrain the design..

Having a one way process like you described would also take away a major purpose of a FuBo (or whatever you want to call it) - that is a resource for coders to help figure out how to implement their ideas and new features. It will be helpful for such a group to be used as a research resource that coders can bounce ideas off for how new features can fit into blender. This is what I mean about a two-way process and working together. Artists certainly don't have a monopoly on new feature ideas, and neither do coders. It's also pointless just submitting feature requests, if nobody wants to code them. That's why we need more collaboration in a kind of 'reserved space' where users don't have to get caught up in the technical stuff, just discuss the functionality.

I agree..

Well a one way process that is like a committee that gives the coders altimatums is a mistake.. But there is power in making designs and
it can control coder's thought processes whether they like it or not. Either
they disagree in which case they will make their point known or
they will try to do their own design work.. Design helps to
reveal what everybody knows to the best of each ability,
while hacking is very individualistic and can be quite blind to what lays ahead..

Yeah I htink feature resuests in the message board are futile, but feature requests are not futile unless they are disorganized and strewn out in a way that is not categorical.. The format in which we are discussing
the design and coding is a bigger problem than what we are proposing for the design.. That's why I'm trying to develop a meta-structure for the
design so we can communicate better..

JA-forreal · Post by **JA-forreal** » Wed Jun 11, 2003 11:36 pm

This (a)-(b) distinction is not really fair. Artists consider things 'cool' too, hence the bells & whistles you can see in 3d packages, which are seldom used... and I've seen 3d coders doing 'cool' things that have helped artists in ways they couldn't even imagine.
We just need both dude! The real challenge is finding a way to make that work... together.-Ton

I would consider myself a power Blender user. And every Blender developement that I need to use, I add it as a part of my 3d productions. And yes as a user of "other 3d software" I know that despite all the features that an app host, the adverage 3d professional only needs a few main tools to get the job done. So I agree with Ton on that issue of needed both of those elements to the Blender project on track. There are some issues Blender needs to meet in order to be as viable as other professional 3d productions apps for instance in the area of dynamics, material handling, geometry system issues, rendering, etc. But These things are already in the process of being improved and most Blender users are up to date with the coders efforts.

Otherwise, the last few posts have really indicated how important it is to keep coders and users separated at the baselevel of feedback, so to speak. I mean absolutely no offense by this, and I'm not trying to be rude in any way, BUT the enourmous gap between coders' and artists' minds is evidently not to be taken lightly. The previous 3 - 4 posts would definitely scare most "ordinary" users away. Far away.

I don't think that coders have to be clandestine about their activities and feel that many areas of their functions are far above the minds of an artist. A cook in a fine restaurant provides a menu of the meals that he or she prepares but they don't have to explain every process of food preparation to their patrons. The menu suffices.

Then here comes the issues of value. Blenders value to artist is cleary understood by all Blender parties. What is Blenders core value to the majority of Blender coders? If the majority of them are computer scientist do they see Blender as a free testing ground for scientific simulations? Or do some plan to offer 3d " carrots in front of artists noses by providing simple useful tools and updates for Blender at the moment. Then do they plan to provide added features to their tools via a working contract with a studio or an item that is sold for profit? We have to make all of our designs for using Blender clear in these areas in order for Blender to grow to new levels of use for all Blender users.

thorax · Post by **thorax** » Thu Jun 12, 2003 12:03 am

Jamesk wrote:Ton:: Thank you for offering a designated forum or mailing list here. We could perhaps get back to that after polling the strict users about what way to go with this.

Otherwise, the last few posts have really indicated how important it is to keep coders and users separated at the baselevel of feedback, so to speak. I mean absolutely no offense by this, and I'm not trying to be rude in any way, BUT the enourmous gap between coders' and artists' minds is evidently not to be taken lightly. The previous 3 - 4 posts would definitely scare most "ordinary" users away. Far away.

So, I'll try gently to get back to my point here::

A---Let us assume that we introduce a forum here or at Elysiun. That forum is strictly for users/artist. We will make sure that the forum is used for very organised, well thought-out feature requests. All participants help out in the making of highly specified "white papers" describing the requests, one by one, in as much detail as possible, from a user point of view. A few selected coders (preferably with a strong connection to the artist community) provide feedback as these specifications are refined as well as weed out any obvious insanities. Aside from those particular tasks, the coders have no say in the matter. This means that the BUIG-forum would have a small administrative unit composed of a number of people from the user community, plus one or two coders.

B---The documents resulting from A above are then passed on to the Functionality Board for further revision. At this point, the requests are now the "property" of the coders' community. That would mean that the users are no longer supposed to participate in further adventures of that particular request, unless those persons making the actual implementation ask for more feedback. This assumes that the request in fact is considered a worthwhile feature by the FuBo, and that it in fact gets implemented

C---From this point on, everything else works just as before. The BUIG would simply provide feature requests - but those requests will be far better organised, refined and complete than the requests made by individuals using the tracker. The request-tracker would of course continue to work as usual. So the material originating from the BUIG would simply constitute an additional source of request-type feedback - but with a special "seal of quality"...

What do you all say? Should we go ahead polling the users? Or what?

I completely agree.. Its hard to make feature requests if you have someone like me constraining your ideas 8^) But a little coder
intervention wouldn't hurt in the case where the users get stuck on
some idea (In the organization you suggested, that would
result in dropping the topic, puting some kind of statement of intent
on the feature and going onto the next..). It would be good for the coders and functionality board to comment on the features suggested
and then to construct a document that the coders can use to guide
their thoughts..

Jamesk · Post by **Jamesk** » Thu Jun 12, 2003 12:27 am

JA-forreal wrote:I don't think that coders have to be clandestine about their activities and feel that many areas of their funcions are far above the minds of an artist.

I wasn't really talking about that - it's not about anything being "far above" or "far below" only "different".

However, I'm beginning to realise that I might very well be the only one to feel this way (which is a bit odd since I am in fact sort of a coder too, only not on the Blender-side of things. So I really should be one of the guys saying that coders and artist have the exact same way of thinking. Which I don't think is true. And which will eventually result in some sort of trouble if it is not dealt with before NGB has grown too mature.)

So I will just leave this contribution as-is. My suggestion about a BUIG as a solution for the issue I brought up in the very first post of this thread is declared as - a suggestion. Nothing more, nothing less.

I _will_ now get back to work on my movie instead

. I hope that these issues will continue to be the object of further discussion. And besides that - no matter what happens, the future is probably a bright one (so, bright I gotta wear shades, *dang-dang-degge-degge-twang-twang*, you remember that one, huh? Timbuk-Three or something....)

thorax · Post by **thorax** » Thu Jun 12, 2003 3:05 am

Well I'm gradually trying to teach myself not to reply to people
who are agreeing with me, because it can be taken as an offense
sometimes.. I think all that we should do now is just
accept that we won't completely agree, due to a lack of differences in
experience, and that we do agree there needs to be a design, we
have some pretty good ideas about how to do this design..
Its at least good at this stage to have a direction and desire to have a
design plan.

There is a little bit of problem in knowing what a structured codebase
can do for development, and why there is a need for one, and
I can sum it up that for the last 5 years of Blender the reason features
were not added quickly enough was not because there wasn't
enough coders, it was that the codebase was not designed to be
changed in ways that allowed for the features users wanted..

Jamesk · Post by **Jamesk** » Thu Jun 12, 2003 10:22 am

thorax wrote:Well I'm gradually trying to teach myself not to reply to people who are agreeing with me, because it can be taken as an offense
sometimes..

Heh heh... weird huh? I don't know if that refers to me or someone else, but I'm just happy that a certain level of consensus can be achieved. Which is a good thing. So, in retrospect, this entire thread is a good thing. I have had a few bugs in my mental processes lately, so maybe I've missed some important pointers every now and then.

thorax wrote: - - - the reason features were not added quickly enough was not because there wasn't enough coders, it was that the codebase was not designed to be changed in ways that allowed for the features users wanted..

This is probably true. That's why the most important thing right here and now is to design a solid framework with extensibility and maintainability as the number one priority. And as far as that goes - only coders have the required knowledge to make those decisions. If the fundamental architecture is a good one, then anything is possible later on.

So, maybe we should just see what Ton can do with the FuBo-concept. It sounded pretty good to me at first, but that thread freaked out a bit, and in the end I got the impression that nobody wanted a Functionality Board either. Gaaahh!

I'll try not to think about these things anymore. Honestly, I told myself already yesterday that I shouldn't pay any more attention to it... I must try to stick to that...

Anyway - Thorax, Dreamerv3, Broken and everybody else::: You've got a lot of great ideas. Don't give up on them. Maybe we should try to join in some sort of allround-massive-hugging situation... Sing a few songs by the campfire... Then get back to work... Feel free to stop me anytime... How about right now?

thorax · Post by **thorax** » Thu Jun 12, 2003 7:59 pm

I don't think anyone has given up on a functionality
board of sorts, just given up on the idea that the functionality
forces changes on the programers or leads the design, its
more just approving and suggesting the form the design should
take. Because the strict non-code-experienced users will
need help in determining what they want in relation to what is feasible,
its like if a user wanted a trashcan in blender we would have to tell them
its just a special directory that deletes stuff when you call a
function to take of the trash.. I'm not saying the users are like this
but some will not know how to describe what they want
and it requires some who can think of the feasibility or the form of
such ideas. I mean the users will approximate a vocabulary they don't know and the functionality board will describe the design
vocabulary they seek.

Some things I'm going to work on providing..

1. feature request categorization system (PHP, MYSQL)
2. Get started quick with UML design tutorial (there is no really complete right way to do UML design, just a way to understand the value in a UML based CASE tool as facilitating a creative process in software design).

I'll have some of that up on my site, I hope by the end of the week.
The first one, 1 may take a while.. But I'll release the sources
so other people can work on it.. I might be able to describe 1 in
terms of UML.. But I'm thinking it won't be complex enough to justify it.

I might even combine 2 to talk about the design of 1, then do 1..
I don't know..

Jamesk · Post by **Jamesk** » Thu Jun 12, 2003 9:45 pm

Sounds very good, thorax! I'm a strong believer in the UML-approach. Even though it may feel like such work progresses painfully slow, it usually ends up making the development as a whole a lot faster.

And, besides - the idea about a BUIG starts to feel... umm... remote. I'm starting to get a very uncomfortable feeling telling me that such a thing would possibly turn into a nightmare.

Those of you who do not visit Elysiun regularly might be interested in checking out this thread and just read the whole thing through...

... and all of that just because of one, single, relatively small feature...

thorax · Post by **thorax** » Thu Jun 12, 2003 11:12 pm

Don't thank me yet.. I went to do the tutorial and I thought
I knew a lot of stuff myself.. The tutorial may just be an introduction
to ArgoUML .. How much do you know about UML?

I found this tutorial link on UML
http://www.sparxsystems.com.au/UML_Tutorial.htm

As I understand UML from other developers is you only need a little
bit to make useful descriptions, like at least you could do a
lot with class diagrams, which is what is used more than any diagram
in UML.. I use use-case diagrams to start out the brainstorming session
and then I will define more precisely what the objects I determined in
the use case were and what classes may be needed to model the
relationship of the systems in the usecase.. Then I will model the
interactions between the objects from the class diagram or from
the use case in an interaction diagram.. But UML doesn't
translate 1to1 with the coding process it just aims to model it
in human terms and to help guide the process..

Is that what you understand of it or is your understanding more solid
of it than that, Jamesk?

Jamesk · Post by **Jamesk** » Fri Jun 13, 2003 12:21 am

Umm... well, that sounds more or less like what I know. UML is quite a science all by itself...

I've used ArgoUML a bit on some java-projects. Nothing big, mainly some simple tests. It was a while ago, so I don't know the current status of the app in question. I remember it was a bit on the fiddly side, yet fully useable.

One advantage with it, as far as Java development goes, is that it can actually go, sort of, 1:1 with the coding process itself, but only to the extent that it can generate all packages with classes and functions, but without the actual implementation of the details of course. But it's a great help in that way. I don't think it will do the same with C++ code generation. I am pretty sure the version I used didn't anyway.

Another advantage is that it performs a lot of checking of the structure while you're working - it pinpoints various logical flaws in the design as you progress. Which also can be a tad bit annoying in the beginning of a project - you get all sorts of warnings about stuff simply because you haven't got around to adding the missing pieces yet... The checkups can be disabled of course, or you can simply ignore them until some of the substructures are fully designed.

thorax · Post by **thorax** » Fri Jun 13, 2003 3:25 pm

Jamesk wrote:Umm... well, that sounds more or less like what I know. UML is quite a science all by itself...

I've used ArgoUML a bit on some java-projects. Nothing big, mainly some simple tests. It was a while ago, so I don't know the current status of the app in question. I remember it was a bit on the fiddly side, yet fully useable.

Well I use Rational Rose Professional J, which I purchased last
year on a group license, so I am familiar with Rational Rose,
but never really got it to work as a interactive devleopment environment.. It might be nice to have a tutorial on that, if you recall how to do it..
But I was just planning to cover the basics..

One advantage with it, as far as Java development goes, is that it can actually go, sort of, 1:1 with the coding process itself, but only to the extent that it can generate all packages with classes and functions, but without the actual implementation of the details of course. But it's a great help in that way. I don't think it will do the same with C++ code generation. I am pretty sure the version I used didn't anyway.

Yeah it appealed to me as being Java targetted.. But the source
generation didn't seem to matter to me.. I am suprised you
got that functionality out of it..

Something I could do with Rational Rose that I don't think its possible
with ArgoUML is backward engineering source code,
you could read in some java source/classes and it could
derive all the class relationships and source code for the classes..
But I never got a complete inetgrated environment where I could
edit java source and have it update in Rose.. I don'r
support ArgoUML has this feature..

Another advantage is that it performs a lot of checking of the structure while you're working - it pinpoints various logical flaws in the design as you progress. Which also can be a tad bit annoying in the beginning of a project - you get all sorts of warnings about stuff simply because you haven't got around to adding the missing pieces yet... The checkups can be disabled of course, or you can simply ignore them until some of the substructures are fully designed.

So you have had a more development oriented approach with ArgoUML than I have, I've used Rose mostly for design but not implementation,
its interesting to hear that ArgoUML is capable of this. Even with Java..
I guess if you can't sync to the sources it doesn't offer much help
if the design is out of sync with the code..

I'll look into ArgoUML to see what is involved in getting it to synchronize with sources.. There is a bunch of work coming my way in RL,
so I may not be able to keep up with the tutes and design work.. I
wasn't expecting all this, I was pretty sure I wouldn't be called up
to do anymore work, but I've got at least 10-40 hour weeks
of work ahead.. And at most 4 years of configures and installs
at 300 sites (argh I don't like how this is sounding, but it could
improve my income situation 8^) ).

Jamesk · Post by **Jamesk** » Fri Jun 13, 2003 4:39 pm

If I remember ArgoUML properly, the syncing (so to speak) was more or less one-way, I'm afraid. It was pretty easy going from the UML-design to a non-implemented framework of packages and classes (with methods and datamembers), but once you started hacking the actual source, there was no apparent way to get syncing back to ArgoUML again.

But I didn't use it all that much to be honest, so there may or may not be features in it that I know nothing about.

thorax · Post by **thorax** » Fri Jun 13, 2003 6:51 pm

Jamesk wrote:If I remember ArgoUML properly, the syncing (so to speak) was more or less one-way, I'm afraid. It was pretty easy going from the UML-design to a non-implemented framework of packages and classes (with methods and datamembers), but once you started hacking the actual source, there was no apparent way to get syncing back to ArgoUML again.

But I didn't use it all that much to be honest, so there may or may not be features in it that I know nothing about.

This is more in line with my experiences.. So I'm thinking
the basic UML can be used to describe the ideas for future blender,
not so much a 1:1 relationship with the source code.
Which is useful design-wise.. Its better than using something like
power point..