Re: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal

[Pete Resnick <[e-mail]>]

On 12/15/03 at 3:29 PM -0800, James Kempf wrote:

>>Certainly a working group is obligated to deal with comments it 
>>receives. But what does it mean for those comments to be "binding"?
>
>To my mind, it means the same thing as in software product 
>development when the QA team comes back to the development group 
>with a list of bugs that caused their regression tests to fail: the 
>code doesn't go to the customers until the development group has 
>fixed the problems.

I'm going to ignore the elephant standing in the room for the moment 
and actually stick to your analogy:

If the QA team finds bugs, it might be the case that the code doesn't 
go to the customer. Or not. If the development team comes back and 
says, "We've told you 20 times that the regression test you people in 
QA are doing is wrong, doesn't represent any customer scenario, and 
should be eliminated; we are not going to waste time fixing that bug 
because it won't effect anybody", the software might very well ship. 
Or perhaps the answer is, "That bug was found too late in the 
process, and it's not like it lops the head off of the user; it's a 
minor user interface flub" and the software will ship. Or maybe the 
development team lead goes to the head of QA and says, "Well, I 
agree, this bug should be fixed. But the folks actually doing the 
coding don't agree, so either we let the bug slide, or if you really 
want I can make a big stink and pass it up to management to deal 
with." And if push comes to shove, you start firing developers if it 
really is something that they need to fix and they refuse.

In the development organizations I've been a part of, either 
development agrees with QA (which happens almost all of the time), in 
which case they fix the bugs, or they don't, in which case either the 
code ships (because QA was wrong or because it wasn't worth arguing 
about) or the management that oversees both groups makes the call. 
Such cases getting to management are rare, I have yet to see 
upper-level management fire someone over such a dispute, and there 
has been no need to give the development lead direct "firing 
authority".

Of course, we do have similar backstops in the IETF (specifically 
2026 section 6.5.1 which I mentioned before), but like the scenario 
above, that should kick in and make it all the way up the chain only 
when the WG in question has completely lost its mind. Folks can 
appeal up the chain, and the IESG can shut down the WG if it's gone 
astray. And there's no reason to give the chair the individual power 
to say "no" if there's no one else saying no.

>What would you call this if "authority" doesn't sound right? The 
>product group manager isn't acting as a dictator, he's trying to 
>make sure the product is salable. The division director isn't going 
>to let him/her ship their code to customers until the bugs are fixed 
>because they both know that the customers won't buy it. Presumably 
>the QA group was selected for their expertise (otherwise, they 
>wouldn't have gotten the job) and their intent is the same as for 
>the product development group: to ensure that the product is of the 
>highest possible quality so customers buy it. Both the development 
>group and the product group manager know this, as does the QA group. 
>The product development manager gets to say when adequate QA has 
>been done, and typically that's based on his/her judgement about the 
>impact of the remaining bugs on customer usability. I don't see much 
>difference here from the case we are discussing, do you?

So here's that elephant in the room: *Of course* there's a 
difference, and I'm a little concerned that you don't see it.

Companies like the one you describe are strict hierarchies. The top 
of the company has the most to gain or lose (monetarily) based on the 
outcome of the efforts of the folks below. The folks further up the 
chain get to choose who is going to do the work below. If the upper 
folks don't like the work being done by the lower folks, they get new 
lower folks to do the work. The upper folks hire some sets of lower 
folks to check the work of the other lower folks. Everything is very 
congenial so long as everyone more or less cooperates. But outside of 
everything working smoothly, you bet it's a dictatorship. Though it's 
nice when there is a consensus among all of the groups, if there's 
not, management has easy ways to solve that problem.

The IETF is not like that. The IETF is a consensus organization. We 
have different levels of consensus (e.g., inside the WG, the whole 
IETF), but at the end of the day, it's the entire population who 
decides whether the work is up-to-snuff. We have some procedures to 
make sure people don't make dumb mistakes along the way (including 
having some folks we think are smart do some final reviews of our 
work), and we've got some management structure to deal with things 
when all hell breaks loose, but even there it's not like the company 
you describe: The IESG can shut down a WG or say "no" to a document, 
but even in those cases, the IESG is supposed to try to resolve the 
conflict and bring the group back to consensus, not just veto. And if 
in the end we can't come to consensus with management, the rest of us 
can appeal the decision of the management, and if we decide that they 
are simply not doing the right thing, we can get rid of them using 
the recall process (or in the extreme, as happened in 1992, change 
the management structure altogether).

Yes, that means we have given our management a good deal of 
responsibility and not very much final authority. There are some 
things that are made really hard by being in an open-membership 
consensus-based organization. Maybe it would be nice if it were 
otherwise. Personally, I kind of like it this way.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: [phone], Fax: [phone]

_______________________________________________
mpowr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mpowr