The operations group at OSAF has been working on clarifying areas of responsibility for key product-related, non-engineering functions at OSAF. Design and program management have been terms we've employed for some time but product management has not been. Sheila Mooney's group (Sheila plus Mimi Yin and now Priscilla Chung), which has been referred to by a variety of informal titles, has been the overall home for both design and program management. Below is a list of key responsibilities in each of these areas.
Additionally, we've now identified a set of corresponding product management functions. Product management responsibilities for Chandler and Scooby will be vested in Sheila's group as well. For now at least, we're going to call Sheila's group "PPD", standing for Product management, Program management, and Design.
Cosmo product management will be done by Lisa Dusseault. Lisa is, among other things, currently the development manager for Cosmo. (As a server product, it has much less in the way of user interface and user interaction issues to be designed or worked on. Therefore, a closer alignment and integration of the development and product definition responsibilities under a single person is sensible.)
Design functions
drive visual and interaction design of products and services drive an open product design process define use cases and target users write specs, create mockups and detailed workflows define and conduct user tests and interview facilitate design list discussions, socialize design proposals
Program Management functions
overall coordinator/driver of delivery of milestone releases facilitate release planning draft and maintain tenets and goals for product releases maintain plan of record, including stickie plan and wiki maintain wiki planning pages prioritize release features participated in bug councils coordinate product dependencies participate in end-of-release process, but does not drive it
Product Management functions
drive product strategy develop vision/mission document and roadmap for products perform market/competitive analysis gather input relevant to product definition from stakeholders articulate applicable general design principles (e.g. Mimi's Nutshell preso) gathers end user feedback and monitoring / managing the adoption process drive product-related messaging
For people not on OSAF staff who are less familiar with OSAF's organizational structure, here is some additional information about who's who to make this memo more comprehensible.
The operations group consists of myself and a set of managers and owner/drivers at OSAF.
Katie Parlante - Chandler development and Architecture Coordinator Lisa Dusseault - Cosmo and Scooby development, Cosmo Product Manager, Standards Coordinator Philippe Bossut - Chandler application team development Sheila Mooney - Program and product management, Design Jared Rhine - Information Technology (IT) Heikki Toivonen - Build and Release Ted Leung - Community Lori Motko - Human Resource and Administration
For more on OSAF governance and the concept of owner/driver, I am copying a recent memo on the subject.
This is not meant to be a complete account of how OSAF governance operates but it is intended to be a useful beginning. While expressed in the language of organizations and applicable to OSAF staff, we expect community volunteers to operate in this same framework.
Comments welcome. A future version of this will be publicly posted.
1. We are an agreement-seeking culture.
At OSAF, we have an agreement-seeking culture. That is, we endeavor to make plans and reach decisions based on achieving wide-spread agreement. Agreement-seeking is not the same as consensus, as consensus tries for universal agreement, which is elusive, if not impossible.
Agreement-seeking as a central principle is also different than majority rule. While voting can play a constructive role as an advisory means of _expression_ of preference, binding procedures of any kind can underemphasize and even undermine the critical role of discussion and deliberation in the shaping of plans. Voting on mailing list is consultative, not binding.
For agreements to be meaningful it is important that those with a stake in the outcome be participants in determining the course of action. So, for instance, it's a matter of common sense that those with technical expertise should be intimately involved in technical decision-making.
Further, given that OSAF is focusing on software for non-technical users, it is also important that end-user interests be represented in the process of creating products and services.
2. Leading is a matter of taking responsibility, not imposing one's will.
We believe in making progress through giving clear responsibilities to individuals. Taking responsibility for something can also be called owning an issue or being a driver. It should not be assumed that owners and drivers typically operate by imposing their own decisions. Driving is primarily a matter of attending to a project with a goal, and taking steps to ensure the goal is reached (or, occasionally, redefining or setting aside the effort). Owners typically solicit input and proposals, enable active participation, and facilitate discussion. In some but not all cases the owner will also be an active content contributor to the matter at hand.
The owner has a responsibility to take multiple points of view into account and to try to reach widespread agreement. If there is disagreement, she or he should use methods to shed more light on the issue, e.g., by taking it to a wider group such as a mailing list.
However, it is also the owner's responsibility to see that a decision is made, and he or she has the right in the end to make that call if in his or her judgment that's the right course of action.
In principle, someone not on OSAF staff could earn an owner / driver roles. We will have to work out a process and ground rules for this.
3. Legitimate decisions are made with reference to the the vision, mission, and values of the organization.
All decisions, but particularly ones about which there is disagreement, should not be made arbitrarily but should be in keeping with the vision, mission, and values of the organization. Decisions gain legitimacy when they can be linked to an underlying set of core beliefs widely shared by the participants.
OSAF's original mission is to create and gain wide adoption of innovative open source application software of uncompromising quality. In 2006 it would be appropriate to consider replacing "application software" with something like "software products and services which serve end-users".
OSAF's core values include:
personal integrity and accountability individual initiative respect responsible risk taking openness and transparency teamwork sustainability
Applying these to mailing list behavior we might say, "Rude and personal comments on mailing lists are disrespectful and not acceptable. Constructive criticism on the other hand is warmly encouraged."
| 