Joey Hess writes ("Re: Technical committee resolution"):
> Ian Jackson wrote:
> > So these two don't seem necessarily to indicate that the decisions
> > were wrong, just that they were ignored. There has indeed been a
> > problem with TC decisions being ignored.
>
> The TC is the decision-maker of last resort. So if such an issue is
> brought to the TC, a decision is made, and that decision is ignored, the
> TC has in a sense failed.
Absolutely. I think this could be solved for the most part by writing
down an NMU policy. `After 2 weeks after the TC decision, the TC
Chairman will normally either authorise an NMU by a suitable person,
or invite a suitable person or people to prepare an unisigned NMU for
review, signature and upload by the Chairman'. Or something.
> Either it's made a technically bad decision,
> or it's taken on an issue it should never have ruled on (since someone
> else was able to make the actual final decision), or it's made a
> decision that while perhaps good in an ideal world, did not survive
> contact with the real one. All of these are in a sense wrong decisions,
> and I see some of each in the examples I listed.
I don't agree with these as the best explanations for the examples you
quoted where the TC's decision was not implemented. I think the best
explanation is that normally that the maintainer did not want to do
the work (which is quite understandable and doesn't imply any
criticism of the maintainer) and no-one else felt empowered to NMU.
> > It is right that we should think about the quality of the TC's
> > decisions. We should have a mechanism that causes us to review a
> > decision, even after it is too late to change.
>
> One of the problems with having a committee who votes on an issue is
> that often no-one in the committee actually assumes responsibility for
> the issue. Which is why TC decisions can easily be ignored, and why
> there's not much review of decisions.
There are usually plenty of interested parties who can take
responsibility. For example, if I had felt empowered to NMU to
implement the md5sum decision I would have done so; wordpress's
proponents said they were committed (and they may have been but
circumstances change).
> I've talked about not liking committees.. I'd rather have a pool of
> people, and when there's an situation where the normal decision
> making processes fail, have one person be selected from the pool and
> be given the responsibily to make the decision, and see it though. That
> includes implementing it (or finding help to do so), following up on it,
> and generally being responsible for it just like a developer is
> responsible for a package.
That's a nice idea but if a problem with the TC is that the decisions
are too poor, reducing the number of people who review those decisions
seems like a bad idea.
Wordpress is an example of a poor decision; I don't think a greater
commitment by a TC member to do security work on it is really to the
point: instead, we should just have not had it in etch.
I think also that many package maintainers would be upset if a single
new-TC-pool member decided to overrule them and also then carry out
their own decision.
But I would be willing to try this. My proposal for letting the TC
and DPL agree its process would make that possible, and would also
make it easier to fix the resulting problems. (Not that expecting
problems means we shouldn't do it, but any new arrangement will have
problems and one of the bugs with the current TC is that we can't fix
the problems I introduced when I set the whole thing up.)
> The Leader may define an area of ongoing responsibility or a
> specific decision and hand it over to another Developer or to the
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Technical Committee.
>
> The TC members seem to be a good pool of people to choose from. I
> respect everyone on it individually and would be happier bringing an
> issue to the TC if I knew it meant any one of them would have to take
> responsibilty for it, rather than all of them (eventually) voting on it.
This would work fine for anything except overrule-maintainer cases.
> I haven't really considered a fair way to select a person from the
> pool. It would be nice if the process was not completly random and
> favored individuals' strengths, but at the same time it shouldn't be
> predictable who will be assigned before an issue is brought, as that
> would encourage gaming the system. Perhaps the overall TC's job would be
> to choose which of its members to assign the issue to.
One way we could perhaps play it is that interested parties would
volunteer and the Chairman would assign the issue. The assignee would
investigate, discuss, etc., and write a judgement with reasons,
present the arguments (for and against) and their analysis. If a
formal decision is needed to overrule the TC would rubberstamp.
If the present TC members were to buy in to such a system, with a
convention that the TC would normally back the assignee, it might
actually work.
> I suspect that such a pool of developers would be much less fun/more
> work to serve on than the current TC, and would probably have a
> naturally higher turnover. I think it would also be more satisfying, and
> might attract valuable people who don't see the current TC as a good use
> of their time.
Certainly being on the TC right now is frustrating.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
