[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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. 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.

> 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.

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.

Note that the constitution already has provisions for something like
this, but we don't use it for technical decisions much, except in the
cases of teams like the release team that take over responsibility for a
whole class of decisions.

       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.

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.

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.

-- 
see shy jo

Attachment: signature.asc
Description: Digital signature


Reply to: