Working Group Process

Revision as of 22:43, 27 January 2011

Process approved in the Technical Steering Group Meeting on January 26, 2011. Please do not make changes to this process, but you can make any suggestions on the discussion page.

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 rather support product evolution by providing market requirements. A high-level description of some of the WG tasks include collecting market requirements and prioritize them, provide a compliance profile and 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. The product manager oversees the requirement management process on a daily basis concludes discussions about requirements implementation.
• 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).

• Conflicts around architecture/requirement decisions will be handled by the project team (i.e. architects and product managers and subsystem maintainers). Only conflicts which otherwise can not be resolved will be reported to the TSG, which has the final say.
• A voting mechanism can be used when needed.
  • A company can have more than one participant active and involved in the WG.
  • A company has only a single vote, regardless of number of participants.

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 will be kicked-off with a small number of committed members - membership in WGs will grow over time.
• 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.
• The 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, as mentioned earlier.

WG Process

1. WG participants submit their companies' requirements / market requirements / feature requests / etc to the MeeGo project via bugs.meego.com.
   • A company that wants to submit market requirements to a WG in which it is participating will create a bug report for that specific requirement and tag it appropriately.
   • The bug report will be tagged as "WG Requirement". This tag is for organizational purposes.
   • The bug report should provide basic information such as requirement title, explanation on the need for that requirement, description of its use, 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 must acknowledge that they will support the implementation of the requirement.
2. The participants of the WG will discuss the requirement and leave comments in the bug.
   • Discussions can also take place in other media such as IRC, mailing list and conference calls.
3. 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 will be prioritized for a specific MeeGo release, and moved to the project team.
   • The requirement will then move from a "WG Requirement" into the queue of the MeeGo release for which it is targeted.
   • The resources to implement it will be allocated, and work will begin.
   • The product and project manager of the MeeGo vertical must participate in these discussions as they drive the implementation work.
4. If a requirement wins the consensus of the WG participants for its need and usefulness, but there are no resources immediately available for implementation, it will be prioritized as low for a given MeeGo release, pending the availability of resources.
   • Once resources are available, the requirement will be prioritized as high for a given MeeGo release, and implementation work can begin.
5. If a requirement does not win the consensus within the WG as needed to be implemented in MeeGo, it will remain tagged as "WG Requirement" in bugs.meego.com for a specific amount of time, to be 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 bug 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, who will introduce you to the WG, help integrate you/your team with the WG and project team of the MeeGo vertical, direct you to the WG mailing list and wiki, and 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. You need to 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 are 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, and they are already active members of MeeGo development. Requirements typically come from Community, Working Groups, and Upstream Projects as illustrated in http://meego.com/developers/requirements. The goal of this WG process is to put in place a framework that companies can follow, 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].

Process Improvements

As we start using this process, we anticipate new ideas for practical improvements. If you have any suggestions for improvements, please assign a bug to ibrahim with your suggestions.

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