[Design] [cosmo] [decision] Detail View

[Ted Leung]

Yesterday during all the discussion on this, Mikeal asked me for a  
pointer to the OSAF governance principles <http:// 
wiki.osafoundation.org/Projects/OsafProjectGovernance>.   Since the  
ops group is working its way toward trying to improve our decision  
making, I thought it would be worthwhile to review this from the  
point of the governance principles.

A reminder: our governance is a hybrid of ideas taken from Mozilla  
and Apache.  It is not a straight Apache style governance.   The OSAF  
governance was designed to allow us to make rapid decisions when  
necessary and to handle situations where it was difficult to reach  
consensus.   There are two key differences:  Voting - strictly  
speaking, in our governance, voting is not binding, it's advisory.     
In many of the decisions that we make, voting actually works as a  
decision making mechanism, because its relatively easy to come to  
agreement, and because it's a pain to send everything to a driver.    
Which brings us to the second key difference: the notion of a driver  
- a person who is responsible for facilitating a decision, making  
sure there is sufficient discussion, making sure that all the  
necessary stakeholders are involved, making sure that the decision  
process happens in a timely fashion, and so on.   It's the job of the  
driver to see that a decision gets made, and the driver is empowered  
to make the decision him or herself if she or he believes that is the  
correct course of action.

In this particular decsion, Priscilla, as the designer for Cosmo is  
the correct driver for the decision.   There are a few additional  
point in-line.  As you read those points, keep this in mind:  I am  
not challenging the decision that has been made.  I am trying to  
clarify how our governance is supposed to work, and in order to do  
that I need to make some comments.   During that commentary, I am  
going to be switching between points of view as the OSAF community  
person and the manager of the Cosmo Engineering team


On May 7, 2007, at 11:00 PM, Priscilla Chung wrote:

> After a short and spirited discussion on the design list, we have  
> looked at the risks at various angles.
>
> We've discussed about risks from a strategic perspective. We looked  
> at the impact on development and QA. In addition, we have shared  
> various opinions on the design.
>
> What are the risk factors which favor one design over the other?
>
> *Schedule risk in development (Getting preview out the door)*
> Matthew estimates there is no additional time required to develop  
> one approach over the other.
>
> *Schedule risk in QA (Getting preview out the door)*
> Mikeal and Adam believe the new design will not take any more time  
> to test.
>
> *Serious objections from any member of the team, this includes  
> anyone at OSAF*
> No one claims they have any serious objections to trying out an  
> alternative design. No design is truly risk free. The proposals  
> represent slightly different compromises and emphasis. Ted  
> cautioned us this is not the last time we'll iterate on the design.

Another risk factor which wasn't listed, but which was voiced by  
multiple people, including myself, was the belief that there was risk  
of more design churn on the new design than on the old design.   The  
summary for a decision needs to be an accurate reflection of  
dissenting opinions, so that people who are being overridden know  
that their concerns have been heard, even if they will not be acted  
upon.

Putting on my hat as the manager of the Cosmo engineering team, I  
think it's important to explain why I am allowing myself to be  
overridden.   Remember that the governance says that the concerns of  
major stakeholders needs to be addressed, and since I am responsible  
for the Cosmo schedule, I count as a major stakeholder for this  
decision.   In this instance, my concern is/was adding additional  
risk to a schedule that is already at risk, and I could stand up and  
say, no, the schedule risk is unacceptable.   Risk assessment is not  
as cut and dried as technical decision making, and there is room for  
legitimate disagreement as to how risky a particular endeavor is.  It  
is apparent from the list discussion is that my assessment of the  
risk is different from the entire Cosmo engineering team and the QA  
folks assigned to work on Cosmo.   Since those people constitute the  
majority of the people that could contribute to design churn (my  
primary concern), I am willing to go with the new design on the  
assumption that those folks are going to do their best to resist  
churning that design.

Ok, back to community guy hat.   So where does that leave us?   We  
have a decision that has been made by the appropriate driver, in this  
case Priscilla.
There was a good faith effort to hear out concerns from people who  
would be impacted by the decision, and the decision has been made.    
In theory, decisions can be appealed to the ops working group, but  
that's not a step to be taken lightly, and I see no reason to do so  
in this case.   So in the end, the governance model worked.   It  
allowed us to make a decision quickly, while preserving our goal of  
being an agreement seeking culture.   This is how it is supposed to  
work.   I know that I am going to do what is necessary to make sure  
that this new plan succeeds, and I hope that this commentary has  
helped illustrate how someone can support the reasoning and outcome  
of our decision making process even when the decision didn't go the  
way that they wanted.

Ted

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20070508/6ca4f4ec/attachment.htm