Re: Who wants to maintain KR list for stable releases?

[Al Boldi <a1426z@gawab.com>]

Natalie Protasevich wrote:
> On 8/30/07, Stefan Richter <stefanr@s5r6.in-berlin.de> 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