Working Group Process

Revision as of 20:13, 27 January 2011

This document provides a proposal on the working group (WG) process. The process is about managing the requirements received by companies participating in any given MeeGo WG.

Goals this proposal aims to achieve:

• Consistency across all MeeGo WGs
• Ease of participation in WG and integration with implementation work
• Lightweight and transparent process

Role of the WG

The WGs are devoted to discussions related to their specific vertical and are accountable to provide input and guidance about market requirements. They are responsible for collecting market requirements from organizations and companies participating in the WG. They identify gaps and develop requirements that detail the need for capabilities. The WGs do not manage the projects but support product evolution by providing market requirements. A high-level description of some of the WG tasks include:

• Collect market requirements and prioritize them
• Collect feature requests and prioritize them
• Provide a compliance profile for the specific vertical
• Provide a hardware profile for the specific vertical

WG Governance

• The WG is led by one person, the WG chair who is appointed by and reports to the Technical Steering Group (TSG).
• Each WG includes a project manager and a product manager (both appointed and report to the TSG). Their role is to oversee the MeeGo vertical from an implementation point of view and they participate in the specific WG of their MeeGo vertical.
• Companies are invited to the MeeGo WGs by the TSG.
• The TSG can delegate incremental membership to the WG.
• WGs use lightweight governance to be effective and efficient. Decisions within the WG follow the IETF-like “rough consensus” model as explained in http://tools.ietf.org/html/rfc2418:

Working Groups make decisions through a "rough consensus" process. IETF consensus does not require that all participants agree although this is, of course, preferred. In general, the dominant view of the working group shall prevail. (However, "dominance" is not to be determined on the basis of volume or persistence, but rather a more general sense of agreement). Consensus can be determined by a show of hands, humming, or any other means on which the WG agrees (by rough consensus, of course). Note that 51% of the working group does not qualify as "rough consensus" and 99% is better than rough. It is up to the Chair to determine if rough consensus has been reached (IETF Working Group Guidelines and Procedures).

• Decisions of the WG Chair which WG members believe do not reflect rough consensus may be appealed to the TSG which has the final say.
• A voting mechanism can be used when needed.
  • A company can have more than 1 participant active and involved in the WG.
  • A company has only a single vote.

WG Logistics

WGs will have their own area within the MeeGo wiki where they publish list of participants, meeting information and minutes, mailing list informations, and post data relative to that WG, etc.

WG Membership

• WGs are kicked-off with a few committed members and grow over time.
• The TSG invites the initial members of the WG.
• Incremental membership can be delegated by the TSG to the WG members.
• Membership in the WG is decided based on:
  • Meritocracy and contributions to the overall MeeGo project
  • Commitment to create a MeeGo product in that specific vertical
• WG representatives are suggested to the TSG and the WG by their respective organizations.
• Product Manager and Project Manager are members of the WG as well as the Project Team. They are nominated for these role by the TSG.

WG Process

1. WG participants submit their companies' requirements / market requirements / feature requests/ etc to the MeeGo project via featurezilla [insert link when available]. A new category will be created to tag those submission as “WG Requirement”. This tag is for organizational purposes.
2. A company that wants to submit market requirements to a WG in which it is participating, fills out a ticket for that specific requirement in featurezilla and tags it appropriately.
3. The ticket provides requirement title, explanation on the need for that requirement, description of its use, possibly a use case description for complex requirements, and a mention if the submitting company is willing to provide resources to contribute to the implementation of this requirement.
   • Companies submitting requirements need to acknowledge that they need to be ready to support the implementation of the requirement.
4. The participants of the WG will discuss that requirement and leave comments in featurezilla. Discussions can also take place in other medium such as IRC, mailing list and conference calls.
5. If a requirement wins the consensus of the WG participants for its need and usefulness, and there are resources available to support its implementations, it gets high prioritized for a specific MeeGo release and moves to the project team. The requirement is then moved from a “WG Requirement” into the queue of the MeeGo release for which it is targeted. The resources to implement it are allocated and work gets going for it.
   • The product and project manager of the MeeGo vertical participate in these discussions as they drive the implementation work.
6. If a requirement wins the consensus of the WG participants for its need and usefulness, however there are no resources to implement it at this stage, it is low prioritized for a given MeeGo release pending the availability of resources.
   • Once resources are available, the requirement is high prioritized for a given MeeGo release and implementation work starts on it.
7. If a requirement does not win the consensus of the WG as needed to be implemented in MeeGo, it is kept in the featurezilla tagged as WG requirement for a specific amount of time decided by the WG. After a specific wait period, such requirements are revisited for a second look.
   • If no change is made regarding this specific requirement, the ticket is closed and the requirement is discarded until further notice. Otherwise it will progress within the process as documented earlier.

Miscellaneous

The role of the TSG:

The TSG sets the direction, tone, and vision for MeeGo, speaks on behalf of the project, and is responsible for project level decisions and overall leadership. Currently, the members of the TSG are Imad Sousou (Director of the Intel Open Source Technology Center) and Valtteri Halla (Director of MeeGo Engineering at Nokia). The TSG meets every two weeks. These meetings are public and open to all. Minutes of the TSG meetings are also public and available at TSG meeting logs. Participate in the TSG meetings at http://wiki.meego.com/Technical_Steering_Group_meetings.

To participate in a MeeGo WG:

1. Contact the WG Chair for the specific MeeGo vertical to introduce you to the WG, and help integrate you/your team with the WG and project team of the MeeGo vertical, and to sign you up with the WG mailing list, wiki, provide you with information about regular meetings, ongoing activities, etc.
   • MeeGo IVI WG Chair – Rudolf.Streif (at) linuxfoundation.org - rudolfstreif
   • MeeGo Handset WG Chair – Ibrahim (at) linuxfoundation.org - ibrahim
2. Identify and assign:
   • A representative from your organization that will participate in the WG of interest to you. The representative will be bringing the requirements from your company and driving them to acceptance within the WG to be part of MeeGo implementation.
   • Engineering resources from your organization to the Project Team of the MeeGo vertical that is of interest to your organization. These resource will be working with the collective MeeGo.com resources on the implementation of the MeeGo stack (core and vertical).

To suggest a new MeeGo WG:

If you are interested in a MeeGo WG that is not kicked off yet or interested in having MeeGo support a new device type (i.e. new vertical), please go to bugs.meego.com and create a bug for that request and assign it to user ibrahim.

Non-commercial community participation in the WGs

Community members are welcome to participate, however they are already doing so. Requirements typically come from Community, Working Groups, and Upstream Projects as illustrated in http://meego.com/community/blogs/samipienimaki/2010/opening-meego-requirements. The goal of this WG process is to put a framework that companies can follow - by using the same methods and tools that the community members are already using. Community members can submit requirements/feature requests/bugs/etc via [bugs.meego.com http://bugs.meego.com].

References

• MeeGo Governance http://meego.com/about/governance
• Community Office http://meego.com/about/governance/community-office
• MeeGo IVI WG Home Page http://wiki.meego.com/in-vehicle