Re: Q: on Debian Bug-Tracking system
On Wed, Sep 27, 2000 at 02:25:36PM -0400, Wayne Topa wrote:
> Would someone know if the bugs listed on debian.org/Bugs
> are the 'current' outstanding bugs or just of all the bugs ever
> posted?
>
> In working up a course outline for an up-coming class, I found
> a bunch of 'inconsistencies' in the doc packages (doc-base, dhelp,
> dwww). I decides to report them and was somewhat dismayed at the
> list of 'old' bugs that are still outstanding. 434 days, 866 days
> and 1192 days, for each of the above packages. Now hopefully these
> 'bugs' are minor and/or do not affect the overall use of the programs,
> or are fixed and the tracking system has not caught up yet. I hope
> the latter. For newbies like my class is, the doc system is the best
> way for them to get the 'warm fuzzy' feeling about how easy the system
> is to work with. If it doesn't work, as advertised in the man pages,
> then that feeling is effected.
>
> I haven't looked at the bug list in awhile and it surprised me.
> I will not refer the students to 'that' page as it puts what, IMO,
> is the Best Linux Distribution, in a less then favorable light.
> Honest, but not favorable.
>
> Thanks for any insight you may have on this. Especially if my
> conclusions are wrong. I *do* want to be wrong.
>
> wt
>
I think your conclusions are wrong. I read your mail yesterday
and whereas it was really interessting, it seemed somehow problematic.
Well, slept one night on it and with that ideas came:
First of all i'm with you, in depreciating the existence of old
bugs (out of date tracking system is equally bad), but i do not
follow about which consequences this implies on presentation in
class.
"Honesty" is one of the essential benefits you get with free software,
and maybe the "warm fuzzy" feeling is not the best starting point
when talking about software. (has to do with beings human or animal
a lot more than with software and technical knickknacks)
I'd recommend the following aproach:
a) Tell what debian is and what it wants to be. Both can
be learnd from the policy.
b) Build up familiarity and confidence in the debian system
by using it (potato that is). Maybe tell stories from your
personal debian history.
c) Point out that there are deficiencies in the debian system
and which mechanisms exist to address theese. This is the
time to mention the bugtracking system, your bugs and the
overly old ones.
d) Show and practice how to contact the debian people, teach
netiquette and how to write a useful mailsubject, last not
least how to cope with high traffic mailing lists.
Getting in contact with people will then create the "warm
fuzzy" feeling.
I think this aproach could be used for any debian presentation
regardless if 15min shorttalk or half a year of intense training.
Finally here is some truths to keep in mind:
- Hiding of deficiencies is an indication of weekness
I think debian is strong enough to address its deficiencies.
If you hide debians deficiencies in class, it is because you
fear your lecturing beeing to weak to present them properly.
(Don't take this too personal, if your lecturing is on debian
your quite good anway. This is just to show that, if you are
tempted to not talk about something it's quite sure you
definitly should talk about it.)
- Perfection is illusion and would be boring anyway
This is the advertising problem, TV-world is perfect in a
way, but real life certainly isn't. This is true with software
and everything including human beings. One should face this
fact sometime and you could consider it an entry ticket to
the free-software community to drop the illusion of perfection.
(recomended reading: Aldous Huxley - Brave New World)
This means aiming at perfection nevertheless but not being
restrained by being imperfect.
- It's more fun to do the big things than the small ones, but
both are equally necessary
Well this is why documentation is rare and often out of date.
I don't really know what to do about this. Maybe there should
be awards to spice the small things. Personally i think it wrong
to seperate small things from the big ones. In documentation
issues the concept of literate programming seems most appealing
to me. Sometimes you can't avoid seperation, i know, but it
means troubles in every single case.
Well, one could think i've been carried away a little, but
that's fine with me. Maybe there's some ideas in it you can
use in class. I'd like to hear how it went sometime. Bth how
about transforming your personal notes and experiences into
a teaching-debian-howto?
Best Regards
Bernd
--
--------------------------------------------------------
bernd.worsch@web.de
-------------------------------------email-preferred----
Reply to: