gravityboy (gravityboy) wrote,

More Steering Committee

I'm glad people have reacted in a largely positive manner to the steering committee idea. It's not really original, but I'm perfectly happy with stealing ideas from other people. I'm going to clarify a few basic ideas here and then address criticism.

The biggest difference between Debian and someone like Canonical or Redhat is that we don't pay employees to do things. We could go that route, but a defining feature of Debian is that it has a bottom-up structure, rather than top-down. I think this makes us unique and we need to do our best to preserve it. I imagine the steering committee to be an extension of this model.

First, the committee would be not be elected by the developers, but would instead be delegated by the DPL. Developers could challenge this delegation in the same manner as any DPL decision. The committee would be very similar to the technical committee in terms of size.

Second, its scope of power would be similar in that it would only relate to the distribution itself, rather than the way the Debian project itself was organized. Its powers would be limited to approving specific improvements within the distribution. These improvements would have to be submitted for approval by the committee, preferably in some sort of specification format similar to the one Ubuntu uses. The committee would then vote on the issue (most likely following the same rules as the technical committee). If they approve it, anyone is free to work on that specific improvement even if it touches on packages they don't maintain. This allows motivated developers to freely work on cross-distro improvements without worry. The committee would ideally be relatively quick to reply to submitted proposals, allowing fairly rapid developments to occur (to facilitate this, proposals must be well thought out).

Further, like the release team, the steering committee would also be responsible for actively working on goals that are set. This would ensure that something actually does get done. These features would give us a group with a limited scope of powers to implement large-scale improvements to the distribution without forcing anyone to do work they don't want to do. In addition, motivated people would have the authority to make large-scale improvements (like consistent theming for example) across many packages they don't maintain. People working on these improvements would be expected to try and cooperate with the normal maintainers as well as possible, so as to prevent problems. Maintainers who have issues can appeal to the technical committee, whose role would remain reactive to solve conflicts as they arise.

Ok, now for the critique from ij, which is a good one. I think the problem with what you suggest is that the DPL simply isn't going to be capable of acting like a good dictator without working full time on Debian for several years. The job is just too big. Allowing them to remain DPL for more than a year is something I don't think many DPL's would opt for anyway, it's just too draining.

The other existing structure is the technical committee, which is a better candidate for taking on this sort of role. The key to the tech-ctte though is that its job is to handle technical disputes. We could expand its role to allow it to set policies and direction, but then who do you appeal to if you don't agree with them? The developer body can override the tech-ctte (with a 2:1 majority) but that adds additional democratic overhead. GR's are draining, and providing another layer for technical decision making allows us to avoid them. Further, I'd like the steering committee and tech committee to have different modes of working. I imagine the steering committee to be more agile, taking a leading role in setting out a vision for the mass of developers to follow and take inspiration from. The tech committee, on the other hand, should be more defensive, carefully deciding on the most difficult issues. Basically the steering committee will looking towards the future, the tech committee will be looking towards the present.

  • Input Hotplug Guide

    There's been a lot of questions about the new input system (referred to as "input-hotplug" or "i-h") that we've enabled in the latest X upload.…

  • How To Follow Major X Issues In Unstable

    It's been a long time since I've done any reasonable work on X stuff, so it's also been a long time since I've blogged. But Julien and Brice* just…

  • I Didn't Think I'd Ever Be Celebrating This Victory

    This is a wonderful day. The various non-free bits of X donated by SGI have, thanks to the efforts of those at the FSF, been relicensed under the…

  • Post a new comment


    default userpic
    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.