On Wed, Mar 03, 2004 at 07:20:11PM -0800, Thomas Bushnell, BSG wrote: > A. What do you think is the greatest challenge facing Debian in the > coming year?
Ensuring that Debian is well-equipped to grow and enjoy further sucess. > What would you do as Project Leader to try and meet this challenge? Reduce opacity of process. Make it easier to find out what the heck's going on, not just with packages (which, as I explained in my platform[1], we already do fairly well), but with people[2][3] and infrastructure as well[4]. > B. What should the Project Leader's role be when Debian comes into > significant and important conflict with other free software > organizations? (As an example, I'm thinking of the conflict with the > FSF about the DFSG vs. GNU FDL.) The Project Leader should avoid the temptation to try to be a personal ambassador to every other organization out there. An elected Project Leader should have some confidence that he is perceived as a reasonable and personable individual, but this should not lead the DPL to act if he or she is the only qualified person to conduct business for the project. As noted in my platform[5], something approaching an ambassadorial process would be a good idea. In many cases, we have developers who already have fruitful working relationships with the organizations we're interested in interfacing with. This is a significant advantage of being a large, vigorous, and diverse project, and it is an advantage the DPL should leverage. This is a good way to further increase Debian's status and esteem within the community. > 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? I have divested myself of my responsibilities as SPI Treasurer, as noted in an earlier mail to this list[6], and (again as noted in my platform[7]), I have transitioned maintenance of the very large, complex package I maintained (XFree86) to a team-developed model. My primary non-Project responsibility consists of holding down a job. I work for Progeny, a company founded by Ian Murdock (the founder of the Debian Project), use my Debian skills on a daily basis in furtherance of job-related tasks, work alongside other Debian Developers, and am part of an organization that values having a cooperative, respectful relationship with the Debian Project. In significant part, Progeny's business model is founded on the vigor of the Debian Project, and Debian's ability to produce a high-quality operating system. It is difficult for me to imagine a working environment more sympathetic to my responsibilties as DPL, and in the event of any conflict I am quite confident that I will have the ear and cooperation of Progeny management in resolving it. > 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. In a word, yes. The New Maintainer Front Desk position was one I identified as one that should be formally delegated in another message to this list[8]. > 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? (I'm > not inviting speculation here on what such a process would look like.) Yes. I think we should have two avenues of removal; one for people who present disciplinary problems, and one for people who are no longer able to contribute. People who have simply become inactive should be treated as much like those who have resigned as possible. We should thank them for their efforts, put them on the emeritus keyring, and find new maintainers for their packages. I think of conduct-based dismissals as being of two kinds; one is for activities that expose the Debian Project, a legally-affiliated organization (such as SPI in the U.S.), or another Debian developer to legal liability. I don't think we have much choice but to expel such people on the first offense, and we have done this in the past. The second type of conduct-based dismissal should be for chronic disciplinary problems that do not rise to the level of exposing anyone to criminal or civil liability. This could include obnoxious abuse of the mailing lists or violation of General Rule 2.1.1 in the Constituion[9]: Nothing in this constitution imposes an obligation on anyone to do work for the Project. A person who does not want to do a task which has been delegated or assigned to them does not need to do it. However, they must not actively work against these rules and decisions properly made under them. I stress that such problems should be chronic. I don't think we should be the type of organization that has a "one-strike-and-you're-out" approach to, say, violations of the Debian Policy Manual, even if those violations are deliberate and premeditated. For disciplinary action to be taken under the "chronic abuse" model, I would expect there to have to be a complaining witness who must be willing to justify why they seek punishment of the developer. That's not necessary in the first case. If we find warez on a project machine, or a Debian Developer sends death threats to the President of the United States[10] from a project machine, then we should act more swiftly (but no less fairly). In both cases, we should permit the person to be so disciplined to speak in his or her own defense, or name a fellow Developer to do so. The proceedings of such disciplinary actions should, I think, be available to Debian Developers, but not to the general public. I am not sure that public shaming of our offenders should be part of our punishment system. On the other hand, I can understand why some people would see this as being in tension with Social Contract[12] clause 4: "We Will Not Hide Problems". I invite suggestions and guidance in this area. [1] http://people.debian.org/~branden/dpl/campaign/2004/platform.xhtml [2] http://people.debian.org/~branden/dpl/campaign/2004/platform.xhtml#s3p2 [3] http://people.debian.org/~branden/dpl/campaign/2004/platform.xhtml#s3p3 [4] http://people.debian.org/~branden/dpl/campaign/2004/platform.xhtml#s3p1 [5] http://people.debian.org/~branden/dpl/campaign/2004/platform.xhtml#s3p6 [6] Message-ID: <[EMAIL PROTECTED]> [7] http://people.debian.org/~branden/dpl/campaign/2004/platform.xhtml#s1 [8] Message-ID: <[EMAIL PROTECTED]> [9] http://www.debian.org/devel/constitution [10] This is not intended to be a hyperbolic example. When I was a student at Purdue University, it apparently was not an uncommon occurence for Purdue students to do this using University-owned computers. It would happen once or twice in an academic year, and the U.S. Secret Service (or maybe it was the FBI) would come out to campus, put the fear of God into whoever was thought to be the perpetrator, and open a government file on the kid that would follow him[11] the rest of his life. [11] Always a "him", as it was described to me... [12] http://www.debian.org/social_contract -- G. Branden Robinson | If God had intended for man to go Debian GNU/Linux | about naked, we would have been [EMAIL PROTECTED] | born that way. http://people.debian.org/~branden/ |
signature.asc
Description: Digital signature
