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: <[🔎] 20040303065714.GB6490@deadbeast.net>
[7] http://people.debian.org/~branden/dpl/campaign/2004/platform.xhtml#s1
[8] Message-ID: <[🔎] 20040303202013.GH8607@deadbeast.net>
[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
branden@debian.org | born that way.
http://people.debian.org/~branden/ |
Attachment:
signature.asc
Description: Digital signature