Simon has a similar view of the situation.

With the stuff I proposed in my last entry and earlier (e.g. bug masters) - I'm well aware that this means someone needs to write a lot of infrastructure code. But given recent improvements e.g. on our bug tracking (user tags, subscription, version tracking) this seems to be working okay. I've never really used launchpad, so I can't comment on what it offers that we might need and where it sucks. And I've said a dozen of times that I hate bugzilla.

Next I'm usually hard to convince that any "infrastructure improvement" will help solving "social" issues. But here it might, if it "weakens" the formal DDs power (isn't god on how the software is packaged and on how patches come in) and strengthens the "occasional contributor" (pending patches repository, DDs can easily approve patches and trigger an upload without being deeply involved with the package, since NMUs are easier to do).

And I'm also aware that my point of view isn't consequent. On one hand I'm convinced that any big "steering" won't work anyway, and those who do the job (read: write the code, write patches) will largely be those who set the direction. Linus didn't just pick a VCS and decide that everyone will have to use it, but actually wrote his own to suit his needs. And others liked it, picked it up, improved it. On the other hand I'm asking people to use packaging practises that allow others to easily contribute. I almost suggested to make it policy to use debhelper and CDBS...

Well, it's one of the things I've learned myself: make it easy for others to contribute - and you'll enjoy it more, because more people will contribute. If it's hard to contribute, people will complain, will file bugs, will argue. If it's easy to contribute, they are more likely to send patches and enhancements. Read: more fun.

It's also one of the reasons I blame for my SELinux work being not too rewarding: it's hard to get going, it's hard to contribute (well, that has improved with the public readable SVN repository for the policy). Less people, less contributions, less fun.

Anyway, I don't see the need for any steering or "global picture". We're not lacking the big goals, but the low-level fun at development.

That doesn't mean I'm strongly "opposed" to the commitee. I just don't see the benefits (but certain costs for electing it. Do we take group applications and vote among groups? Then we could just have the DPL nominate the steering comitee. Or will we vote on individuals, with the top n becoming the board? Then we'll have lots of platforms to read (=boring, not fun), and we'll probably have the same problems at a different level, different opinions in the board.

And, given that the DPL has no real power, will the board have any?

We also have a technical comittee. Does it have any power (well, it's supposed to, but was it ever enforced)? Did anyone ask it about something recently?