Natalie Protasevich wrote:
> On 8/30/07, Stefan Richter <[email protected]> wrote:
> > Al Boldi wrote in "Designers and Builders (was: Who wants to maintain KR
> > list for stable releases?)":
> > | So, what's wrong with tapping into people's design suggestions, and
> > | allowing others to implement it?
> >
> > Design suggestions should really come from people who also know a lot
> > about the how-to. This is even true to some degree about feature
> > requests. Besides, I've got a feeling that regardless of the field of
> > ????? one works in, someone can only be a truly good designer if she or
> > he has also been a builder.
>
> Sometimes you can feel that the suggestion comes from Unix veteran, or
> one who does a lot of linux programming in user land. Their opinion is
> often valuable.
Exactly right.
The important part in designing isn't the how-to but rather understanding the
concepts involved. Once you have the concepts straight, implementation
becomes a matter of which path to take.
> > But back to the discussion. A tracker is not a good tool for
> > brainstorming sessions, except perhaps for capturing conclusions after
> > the brainstorm, as far as they are suitable as input for actual work.
> >
> > Also, "*allowing* others to implement it" has a strange ring to me.
> > Where I am around, there are always far too few people who fix things
> > and build things. But very, very occasionally there is someone new who
> > wonders if there is an interesting TODO item which is perhaps in the
> > reach of his abilities. Contributing a cleanup or an actual feature is
> > typically much easier than fixing an open, tracked bug. (The bugs which
> > end up in the bugtracker are usually the difficult ones.) The
> > contributor learns something and, in a rare turn of events, may
> > eventually become able and willing to join the bugfixing.
>
> Yes, indeed, one should really know the code in and out to do things
> right. OTOH, not everyone has time to fix bugs in his department, or
> it's just single person trying to handle all work. I suggest that in
> this case our masters could first outline what needs to be done and
> write it down in the bugzilla. This will 1) give a warm feeling to
> reporter and everyone else that the problem is noticed and not taken
> lightly and 2) give people with active and curious minds chance to try
> solving a problem (my guess that would be many reporters themselves,
> they often ask "what can I do and how can I fix this" and some more
> junior developers looking for useful exercise and just need
> directions.) At least some good debugging will come out of it, and no
> harm...
Agreed. But when I responded to this thread by changing the subject, because
I felt it was somewhat OT to tracking, I meant to question the mentality of
trying to nullify design suggestions for the mere reason of not submitting a
prototype. Now, prototyping is a great way to refine your end-product, but
it's a terrible waste of time in terms of articulating design-goals.
IMHO, in the interest of keeping ahead of the competition, we should
encourage people to express their design suggestions instead of discouraging
them.
Thanks!
--
Al