Re: Technical committee resolution

[Ian Jackson <ian@davenant.greenend.org.uk>]

Joey Hess writes ("Re: Technical committee resolution"):
> Ian Jackson wrote:
> > I haven't heard anyone suggest that the TC is actually making wrong
> > decisions.
> 
> Well..
> 
> #104101: The TCs resolution that kernel sould have VESA fb compiled in
>     was ignored by its maintainer, who instead waited for it to be fixed
>     upstream so it could be built as a module.
> #164591: The TC decided that md5sum </dev/null should not be "annotated" with
>     "-". This must have been the wrong decision, since it was reversed
>     in the TC's ruling on #341839

The TC's opinion seemed to me to be that it was the right decision at
the time of #164591, but given that it hadn't been implemented it was
now too late.  (Of course I was in the minority on #341839 and I may
be wrong.)

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.

> #413926: The TC decided wordpress should be shipped in etch, despite the
>     security team's desire to not support it. The security team's tracker
>     now lists 11 open security holes for the version in etch; the team
>     has so far managed one DSA that closed 4 other holes.

Of course I agree with you and I can say `I told you so' since I voted
against the decision to include wordpress.  But let me try to step
back a bit:

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.

It could be something so simple as a rule a bit like this:

  `I told you so'
  ---------------

  If you were involved in a TC decision which was taken at least 12
  months ago, and you think evidence and experience now shows that
  important parts of the argument on either side, or the actual
  decision, were wrong, then, you are encouraged to bring this to the
  attention of the committee.

  For example, if arguments were raised that there would be a
  compatibility problem with a certain change, but in fact the change
  was deployed and there were no compatibility problems, then the
  Committee would like to know.  Conversely if it was argued that the
  Committee's decision would cause problems which have indeed now
  arisen, we should be told.

  "I told you so" mails should name the specific TC members who
  allegedly made the mistake(s).  The other TC members and the DPL
  will use this information during the regular vote to reconfirm a
  person's TC membership; the Chairman will collate and summarise the
  alleged "I told you so"s.

  Extensive discussion of "I told you so" situations should be
  avoided; the purpose is to inform other TC members' views, not to
  convince the target that they were wrong.

Perhaps this is too vicious but I think as TC members we ought to
expect this kind of criticism and cope with it.

Ian.