* Thomas Bushnell, BSG <[EMAIL PROTECTED]> [2004-03-03 19:20]: > A. What do you think is the greatest challenge facing Debian in the > coming year? What would you do as Project Leader to try and meet > this challenge?
I think I have covered this pretty thoroughly in the "My goals" section of my platform (http://www.debian.org/vote/2004/platforms/tbm). I think that the first two points in this section are the greatest challenge in the near future: fixing our release cycle, and improving communication in the project, adding more transparency and adding more man power to our core teams. Problems with our release cycle and with communication led to increased frustration in recent months; people are getting demotivated, they have the impression that Debian is falling apart. I think these are the most important problems to tackle in the coming year which is why I say in my platform that we have to put "extra emphasis on the internal functions in the coming term". Feel free to ask more specific questions based on my platform. > B. What should the Project Leader's role be when Debian comes into > significant and important conflict with other free software > organizations? I think it is very important to work together, and to resolve these problems and conflicts. We are _one_ community, and we have to make sure that this remains to be the case. I am also worried about the "Free Software" and the "Open Source" communities drifting apart further - there is an increasing number of licenses which are Open Source compliant, but which fail to meet our DFSG. I think we have to work together with other organizations, and not just on a technical basis (where we're doing pretty well). > C. Being the Project Leader is a major responsibility. What are the > other Project-related and non-Project-related responsibilities which > would compete for your time, and how would you manage that conflict? Project-related: I lead the New Maintainer Front Desk, and I am involved in various QA activities, mainly in tracking inactive maintainers. I have shown during my first year as DPL that I can handle these tasks while being DPL. Also, more QA people are getting involved so that should reduce some work load. Non-Project-related: I started a PhD about quality management in free software in January. Fortunately, my PhD and my activities in Debian overlap to some extend. I have shown during the last year that I can work on Debian basically full-time and yet perform my studies with excellent results. I therefore see no conflicts or problems with regards to time. > D. People become Debian Maintainers by a complex administrative > process, involving three different folks who have to agree on any new > Maintainer: the Advocate, the Application Manager, and the Accounts > Managers. I'm not interested in the details of how this process > works. My question is: Should the Constitution specify at least who > has the actual formal approval over this process? In other words, > right now it's not clear what the exact lines of authority are. I think it's quite clear who the authority has. The constitution (8.1.2) explicitly grants the rights of "including approving or expelling Developers" to a delegate, and this delegate is the Debian Account Manager (DAM). As such, the DAM has the overall responsibility for the NM process, with assistance from the NM Front Desk. The NM documentation currently available is quite complete, but rather disorganized and not entirely up-to-date. A complete re-write is on my TODO list (as NM Front Desk), and this re-write will better document procedures for advocates, Application Managers and the DAM. A few months ago, the DAM defined the process for DAM rejections quite clearly. In summary, some procedures are quite well documented, while others (mostly AM related tasks) are to some extend "learned by doing" (under the supervision of the NM Front Desk). However, more documentation is forthcoming, and a first step were my postings about preparing good AM reports, see http://lists.debian.org/debian-newmaint/2003/debian-newmaint-200303/msg00018.html and http://lists.debian.org/debian-newmaint/2004/debian-newmaint-200402/msg00010.html To summarize: I think the constitution does not need clarification in this regard, but more documentation about the whole NM process is important. > E. Debian does not have a formal process for removing a delinquent > developer. Should we have one? And if so, what are the sorts of > things for which it would be appropriate to remove a developer? Basically, (severe) violations of the DMUP are things which would lead to the removal of a developer. I think a formal process would be good, and I suggest it should be developed when there is a concrete case where the expulsion of a developer is proposed (It would be nice to formalize it now, but given that expulsions are extremely rare I don't think the effort should be spent before there is actually a concrete need for it. If someone is volunteering to do it now, that would be fabulous, of course!). So far, to my knowledge, about 2 developers have been expelled many years ago. If something like this comes up again, the first step would be to review how those expulsions were handled. (I don't know myself since I wasn't around or involved with this; as DPL, I would first talk to the people who handled those expulsions, and ideally also talk to the expelled developers to get their opinion on how to handle expulsions in a human way). -- Martin Michlmayr [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
