appeal mechanisms was Re: Ombuds-process
moore at cs.utk.edu
Mon Jun 30 01:16:23 CEST 2003
On Sun, 29 Jun 2003 22:00:12 -0400
"Joel M. Halpern" <joel at stevecrocker.com> wrote:
] Hence, the appeals process was not created to make it easy to cause
] extensive review of IESG actions. The IETF last call is the intended
] mechanism to make it easy for folks to provide useful input. And that
] (sensibly) is before the decision.
] So, my question becomes what problem do we want to solve?
] Do we really want to make appeals of IESG decisions easy and common? I
] hope not.
] Is there a problem where people feel that their input has not been
] considered, and it is too hard to force the issue? Probably.
] Is the underlying problem then that people think that they are being
] ignored when in fact their input was considered?
] Or is there an underlying problem of the IESG ignoring important input? I
] hope not, but it is certainly not impossible.
] Or is there a problem that the appeals process, by nature difficult, is
] simply perceived as too hard, even if it is appropriate for the job?
] Or is there a problem of insufficient explanations of the decisions that do
] get made?
I think the problem is that too much of what gets to IESG has failed to
consider important design considerations and/or is of poor quality.
By the time the documents get to IESG, there's little that IESG can do to fix
the problem - and there is a significant chance that *any* action that IESG
takes would either warrant an appeal (say, because it approved a document
containing technical errors), or cause someone to believe that IESG had acted
When working groups do their jobs properly, there's already consensus on the
document (not just within the working group, but through the entire community)
*before* the document goes to IESG, and IESG's job is easy.
So what we need to do is insist that working groups make IESG's job easy.
More information about the Problem-statement