On Mon, Mar 04, 2002 at 08:24:01PM +0100, Marcelo E. Magallon wrote: > With that as an starting point, do you have any opinions regarding > this topic? Do you regard Debian as an "open enough" organization, > or do you think there's room for improvement?
Both. The level of transparency has to be balanced against the amount of labor required by the participants to achieve that transparency. A lot of times, things get done in our Project just because someone decides to roll up his sleeves and do it. I don't want to erect bureaucratic walls to impede that. I think that for the most part Debian has earned and deserves its reputation for openness. However, there's always room for improvement. What I think is lacking is not so much open discussion forums -- or the use thereof -- for the implementation of technical solutions, but of public, accessible, advertised, and structured documentation of some of these solutions. A lot of stuff we do, especially our internal processes, are documented on an ad-hoc basis in a single email posting on one of several different lists, or not documented at all. For example, I had a dispute with the Technical Committee a while back over whether it was acceptable for an .orig.tar.gz to be re-uploaded with different contents (a licensing problem forced me to change it). A majority of the Technical Committee felt I was stupid for attempting to do this, because the package pools system was designed in such a way that you can't (and not without some justification). The biggest problem I had was that I couldn't find where this was written anywhere. You could do this sort of thing before we had package pools, and all of a sudden you couldn't. I was chastised for taking advantage of an undocumented feature in the past, but I still perceived this as an interface change -- as a package uploader, I was putting my packages in the same old place, using the same old techniques, and had no expectation for formerly legal uploads to be rejected. This is the sort of thing that documentation was born to solve. So, in my opinion, it's not so much that we don't take advantage of our open forums to practice brainstorming and development, but that sometimes we do our fellow developers a disservice by failing to document what we do, or failing to ensure that our documentation is known about and accessible. In turn, this problem can be blamed on a needlessly high amount of friction involved in making documentation available. I don't think people deliberately fail to bring their cool new tools -- including their caveats -- to people's attention. I think we're missing a mechanism to make it easy for them do so. As I mentioned recently in debian-devel, I'd like to see more usage of debian-devel-announce for this purpose. It might also be a good idea to explore what we can do with http://www.debian.org/devel/ to make it an even better resource for our developers. I think there are people with sufficient talent and motivation to accomplish the above; there just needs to be a bit of an organizational effort, and that is one of the primary duties of the DPL, in my conception of the job. > 2. Historically Debian has had project leaders varying between two > extrema: those who were very vocal and could be seen constantly > participating in a productive way in several internal and external > fora and those who tended to take part in discussions to make > succint statements regarding their opinion of the subject at hand. [...] > Between these two cases, what kind of leadership do you foresee > yours to be? I think the DPL should only try to do -- as DPL -- that which the Project isn't managing to accomplish on its own. The best thing the DPL can do is identify the people with sufficient talent and motivation to accomplish a given task, and encourage (or authorize) them to do so. Expecting the DPL to single handedly solve several major problems at once asks too much of the office, and belittles the skills other Developers. I think the DPL should: A) Match technical/procedural problems with the people that can solve them. 1) Identify problems that aren't being solved; 2) Identify one or more individuals capable of solving that problem; 3) Invite and empower the people in 2) to handle 1); 4) Ensure that the people in 3) have what they need to deliver a solution; 5) Accept and implement that solution unless there is a good reason not to. B) Identify areas where the Project is stalled due to heavy, irreconcilable contention: this means drafting and submitting a General Resolution to break the deadlock. C) Evangelize and represent Debian to the rest of the world. I do think the DPL should not hesitate to involve himself in technical discussions or project teams such as those described in A) above; however, the DPL should participate in such project teams as a member, not a leader. Otherwise, he's not delegating. There may be a task from time to time that the DPL feels very strongly personally invested in, and should not delegate; however, he (or she) needs to be sure that his approach is going to be acceptable to the majority of developers. Otherwise he risks provoking dissent, or having his work overturned by a General Resolution. This is why I think it's best if the DPL delegates. There shouldn't be shortage of people in this project that the DPL can trust to make good decisions. If there is, then I don't think he can be truly representative of Debian. Being DPL means having respect for the people who elected you. -- G. Branden Robinson | Debian GNU/Linux | If ignorance is bliss, [EMAIL PROTECTED] | is omniscience hell? http://people.debian.org/~branden/ |
pgpoFzF6wlRHu.pgp
Description: PGP signature
