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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
