Re: Question for candidate Towns

[Martin Schulze <joey@infodrom.org>]

martin f krafft wrote:
> also sprach Martin Schulze <joey@infodrom.org> [2005.03.11.1715 +0100]:
> > > That people who would like to know more about Debian internals
> > > have no easy way of finding out, and if they approach those that
> > > know at the wrong time, or not in the way those would expect,
> > > they get flamed and blacklisted.
> > 
> > As you weren't able to provide a single problem (but only listed
> > a non-problem), I consider you're just a firefeeder.
> 
> This is part of the problem: you (as well as some others) are in
> a situation in which you fail to understand how others in the
> project feel. You know a lot about the project, so it's all obvious
> to you. There are people among us who have not been part of Debian
> since 1.1, but who would like to know more about what's happening
> behind the curtains. However, those people are often told to RTFM or
> go spend time in the code, or just not taken seriously.

When the code is public, rtfm is the proper answer.  One might add
"document it properly afterwards" as well, though.  When the data is
available as well, that's best.  Some data cannot be made available
for legal or other binding obligations (new queue, security archive).

If you feel that some bits are missing and need to be documented
better, point them out and get them documented better, maybe by doing
it on your own.

I know a lot about the project because I've been involved in many
parts.  Other developers are involved in many parts as well.  Some
other developers mostly whine about not being involved without trying
to understand.  *sigh*

> No, I do not have (nor do I want to present) a single example for
> you, Joey. I am sure that you will dissect just about anything
> I write. All the better if there is an easy way to find out

I hope to be able to, but I cannot guarantee that I am.  I believe
that most parts of the project are either documented or publically
available in source form so that all developers can educate
themselves.

> everything about the project. It just does not help much if every
> aspect is documented in a different place, or using a different
> paradigm.

Then try to unite the documentation instead of blindly bashing and
whining.

> What you fail to see is that there is something daunting about
> a project of this size and complexity to those who are trying to
> understand it top-down, rather than having been part of building it
> bottom-up.

What you fail to see is that the bits are available and that you
"only" have to build the large picture.  If you're too lazy to do so,
it's not the job of the people working on essential corners of the
project to educate every random Johnny Sixpack for the sake of it.

Regards,

	Joey

-- 
If nothing changes, everything will remain the same.  -- Barne's Law