I am taking this to -devel. Please remove -vote from all replies.
... and sorry for the late reply.
also sprach Martin Schulze <joey@infodrom.org> [2005.03.14.0826 +0100]:
> When the code is public, rtfm is the proper answer.
This answer seems logical to you and I. It is, however, not the
didactically correct answer for everyone.
> One might add "document it properly afterwards" as well, though.
Yes, or else we'll be in ten years where we are right now. :/
> Some data cannot be made available for legal or other binding
> obligations (new queue, security archive).
For instance, where would I go to obtain the meta-information about
this? I learnt about the NEW queue write-only restriction on IRC per
chance. Is this (LFAQ item) documented somewhere publicly?
> 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.
Of course. I am doing so, if not only by writing (well, having
written) an exhaustive reference book on Debian.
However, I should point out again that this is not about me, and
that many people are (a) either not willing to document, or (b) are
too daunted by the complexity of our project and thus don't even
know where to start.
> > 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.
The question is whether it's easily or readily accessible. I believe
that source code is *not* the right medium for everyone wanting to
get involved. You may disagree with me (we are not here to reach an
agreement on this), but let it be said that we often tell people
that coding is not required to contribute to Debian, that there are
many other areas where help is needed... the problem is that there's
quite a dampening effect on motivation when one does not know the
project for which one is working (sorry for the awkward wording).
Another, related issue is that the infrastructure itself may be
documented or available for scrutiny, but its use or status are
obscure(d). Bas gives a good example in his recent email to
debian-devel[0].
0. [🔎] 20050315224710.GB31214@iasoon.debian.net
> > 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.
http://debianbook.info
The book is still targeted at users and does not include all the
information relevant to developers, but a bunch of stuff is still
included. Moreover, depending on its success, I may followup with
a developers' book.
> > 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.
Of course I agree with you. However, "RTFM" or "UTSL" is not the
answer to every question.
Let's go hypothetical. If you will, maybe you can show me where
I would find answers to the following questions:
1. I have been a system administrator for years, with experience
in both, multi-user support as well as critical infrastructure
maintenance. I would like to become a Debian System
Administrator but cannot contribute any machines at the moment.
What do I do?
2. I want to become a member of the security team. I screen
full-disclosure and other mailing lists and try to take a stab
at reproducing and/or fixing problems whenever I find the time.
In the past, it has happened that messages I forwarded to the
security team have been politely acknowledged as "yeah, we know
about this already", and patches I submitted have been rejected
because other fixes were already in place. I realise that the
security team must maintain a certain level of secrecy, but how
am I supposed to contribute when I am excluded? I have been
told about a database for security issues, but so far there
seems to be no such thing. I would help with this issue, but
I do not have access to the information.
I could probably conceive other examples, but that's not the point.
I see Debian as a meritocracy, and the way to receive privileges is
to contribute and be pro-active. However, it cannot be the goal to
expect from willing users to figure out everything about a job all
by themselves prior to being able to gain recognition for the
contributions they make -- if they are lucky enough to be considered
useful by current holders of the position strived for. If this is
actually intended, then it is highly inefficient. If it is not
intended, then maybe Debian wants to do something about it, and if
not only to stop cold those rumours about an alleged cabal.
I wonder if Anthony's proposal about mentoring extends to domains
beyond the duties of the standard Debian developer...
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, admin, user, and author
`. `'`
`- Debian - when you have better things to do than fixing a system
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
Attachment:
signature.asc
Description: Digital signature