I am taking this to -devel. Please remove -vote from all replies. ... and sorry for the late reply.
also sprach Martin Schulze <[EMAIL PROTECTED]> [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. [EMAIL PROTECTED] > > 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 <[EMAIL PROTECTED]> : :' : 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!
signature.asc
Description: Digital signature