Views
Working Group Process
From MeeGo wiki
(Difference between revisions)
m (→WG Process) |
(add link to list of Bugzilla keywords) |
||
| (8 intermediate revisions not shown) | |||
| Line 1: | Line 1: | ||
| - | + | Process approved in the [[Technical Steering Group meetings|Technical Steering Group Meeting]] on [http://trac.tspre.org/meetbot/meego-meeting/2011/meego-meeting.2011-01-26-20.00.html 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: == | == Goals this proposal aims to achieve: == | ||
| - | * Consistency across all MeeGo | + | * Consistency across all MeeGo Working Groups |
| - | * Ease of participation in | + | * Ease of participation in Working Groups and integration with implementation work |
* Lightweight and transparent process | * Lightweight and transparent process | ||
| - | == Role of the | + | == Role of the Working Group == |
| - | The | + | The Working Groups 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 Working Groups. They identify gaps and develop requirements that detail the need for capabilities. The Working Groups do not manage the projects, but rather support product evolution by providing market requirements. |
| - | A high-level description of some of the | + | A high-level description of some of the Working Group tasks include collecting market requirements and prioritize them, provide a compliance profile and a hardware profile for the specific vertical. |
| - | == | + | == Working Group Governance == |
| - | * The | + | * The [http://meego.com/about/governance/working-groups Working Group] is led by one person, the Working Group chair who is appointed by and reports to the Technical Steering Group (TSG). |
| - | * Each | + | * Each Working Group 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 Working Group 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 | + | * Companies are invited to the MeeGo Working Groups by the TSG. |
| - | * The TSG can delegate incremental membership to the | + | * The TSG can delegate incremental membership to the Working Group. |
| - | * | + | * Working Groups use lightweight governance to be effective and efficient. Decisions within the Working Group follow the IETF-like rough consensus model as explained in [http://tools.ietf.org/html/rfc2418 http://tools.ietf.org/html/rfc2418]: |
<blockquote> | <blockquote> | ||
| - | 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 | + | 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 Working Group 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). |
</blockquote> | </blockquote> | ||
| - | * 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. | + | * 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 voting mechanism can be used when needed. | ||
| - | ** A company can have more than | + | ** A company can have more than one participant active and involved in the Working Group. |
| - | ** A company has only a single vote. | + | ** A company has only a single vote, regardless of number of participants. |
| - | == | + | == Working Group Logistics == |
| - | + | Working Groups 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 Working Group, etc. | |
| - | == | + | == Working Group Membership == |
| - | * | + | * Working Groups will be kicked-off with a small number of committed members - membership in Working Groups will grow over time. |
| - | * Membership in the | + | * Membership in the Working Group is decided based on: |
** Meritocracy and contributions to the overall MeeGo project. | ** Meritocracy and contributions to the overall MeeGo project. | ||
** Commitment to create a MeeGo product in that specific vertical. | ** Commitment to create a MeeGo product in that specific vertical. | ||
| - | * | + | * Working Group representatives are suggested to the TSG and the Working Group by their respective organizations. |
| - | * Product Manager and Project Manager are members of the | + | * The Product Manager and Project Manager are members of the Working Group as well as the Project Team. They are nominated for these role by the TSG, as mentioned earlier. |
| - | == | + | == Working Group Process == |
| - | # | + | [[File:Keyword_categories.png|thumb|400px|Keyword categories]] |
| - | #* | + | # Working Group participants submit their companies' requirements / market requirements / feature requests / etc to the MeeGo project via [http://bugs.meego.com bugs.meego.com]. |
| - | + | #* Working Group requirements are submitted by [http://bugs.meego.com/enter_bug.cgi creating a bug report] and, using the [https://bugs.meego.com/describekeywords.cgi "Keywords" field], tagging the bug using the appropriate keyword. | |
| - | #* The | + | #* The bug report must include the following information: |
| - | #* Companies submitting requirements | + | #** ''Requirement title'' |
| - | # The participants of the | + | #** ''Explanation of the need for the requirement'' |
| - | #* Discussions can also take place in other | + | #** ''Description of its use'' |
| - | # If a requirement wins the consensus of the | + | #** ''A use case description for complex requirements'' |
| - | #*The requirement | + | #** ''Implementation resources the company is willing to provide '' |
| - | #*The resources to implement it | + | #* Companies submitting requirements must acknowledge that they will support the implementation of the requirement. |
| - | #* The product and project manager of the MeeGo vertical participate in these discussions as they drive the implementation work. | + | # The participants of the Working Group will discuss the requirement and leave comments in the bug. |
| - | # If a requirement wins the consensus of the | + | #* Discussions can also take place in other media such as IRC, mailing list and conference calls. |
| - | #* Once resources are available, the requirement | + | # If a requirement wins the consensus of the Working Group 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. |
| - | # If a requirement does not win the consensus | + | #*The requirement will then move from a "Working Group 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. | ||
| + | # If a requirement wins the consensus of the Working Group 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. | ||
| + | # If a requirement does not win the consensus within the Working Group as needed to be implemented in MeeGo, it will remain tagged as "Working Group Requirement" in bugs.meego.com for a specific amount of time, to be decided by the Working Group. 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 == | == Miscellaneous == | ||
| Line 59: | Line 64: | ||
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 http://wiki.meego.com/Technical_Steering_Group_meetings]. | 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 http://wiki.meego.com/Technical_Steering_Group_meetings]. | ||
| - | === To participate in a MeeGo | + | === To participate in a MeeGo Working Group: === |
| - | # Contact the | + | # Contact the Working Group Chair for the specific MeeGo vertical, who will introduce you to the Working Group, help integrate you/your team with the Working Group and project team of the MeeGo vertical, direct you to the Working Group mailing list and wiki, and provide you with information about regular meetings, ongoing activities, etc. |
| - | #* MeeGo IVI | + | #* MeeGo IVI Working Group Chair – Rudolf.Streif (at) linuxfoundation.org - [http://meego.com/users/rudolfstreif rudolfstreif] |
| - | #* MeeGo Handset | + | #* MeeGo Handset Working Group Chair – Ibrahim (at) linuxfoundation.org - [http://meego.com/users/ibrahim ibrahim] |
| - | # | + | # You need to identify and assign: |
| - | #* A representative from your organization that will participate in the | + | #* A representative from your organization that will participate in the Working Group of interest to you. The representative will be bringing the requirements from your company and driving them to acceptance within the Working Group 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). | #* 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 | + | === To suggest a new MeeGo Working Group: === |
| - | If you are interested in a MeeGo | + | If you are interested in a MeeGo Working Group that is not kicked off yet, or are interested in having MeeGo support a new device type (i.e. new vertical), please go to [http://bugs.meego.com bugs.meego.com] and create a bug for that request and assign it to user [http://meego.com/users/ibrahim ibrahim]. |
| - | === Non-commercial community participation in the | + | === Non-commercial community participation in the Working Groups === |
| - | Community members are welcome to participate, | + | 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 http://meego.com/developers/requirements]. The goal of this Working Group 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 [http://meego.com/users/ibrahim ibrahim] with your suggestions. | ||
== References == | == References == | ||
* MeeGo Governance http://meego.com/about/governance | * MeeGo Governance http://meego.com/about/governance | ||
* Community Office http://meego.com/about/governance/community-office | * Community Office http://meego.com/about/governance/community-office | ||
| - | * MeeGo IVI | + | * MeeGo IVI Working Group Home Page http://wiki.meego.com/in-vehicle |
Latest revision as of 13:08, 9 August 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.
Contents |
Goals this proposal aims to achieve:
- Consistency across all MeeGo Working Groups
- Ease of participation in Working Groups and integration with implementation work
- Lightweight and transparent process
Role of the Working Group
The Working Groups 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 Working Groups. They identify gaps and develop requirements that detail the need for capabilities. The Working Groups do not manage the projects, but rather support product evolution by providing market requirements. A high-level description of some of the Working Group tasks include collecting market requirements and prioritize them, provide a compliance profile and a hardware profile for the specific vertical.
Working Group Governance
- The Working Group is led by one person, the Working Group chair who is appointed by and reports to the Technical Steering Group (TSG).
- Each Working Group 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 Working Group 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 Working Groups by the TSG.
- The TSG can delegate incremental membership to the Working Group.
- Working Groups use lightweight governance to be effective and efficient. Decisions within the Working Group 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 Working Group 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 Working Group.
- A company has only a single vote, regardless of number of participants.
Working Group Logistics
Working Groups 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 Working Group, etc.
Working Group Membership
- Working Groups will be kicked-off with a small number of committed members - membership in Working Groups will grow over time.
- Membership in the Working Group is decided based on:
- Meritocracy and contributions to the overall MeeGo project.
- Commitment to create a MeeGo product in that specific vertical.
- Working Group representatives are suggested to the TSG and the Working Group by their respective organizations.
- The Product Manager and Project Manager are members of the Working Group as well as the Project Team. They are nominated for these role by the TSG, as mentioned earlier.
Working Group Process
- Working Group participants submit their companies' requirements / market requirements / feature requests / etc to the MeeGo project via bugs.meego.com.
- Working Group requirements are submitted by creating a bug report and, using the "Keywords" field, tagging the bug using the appropriate keyword.
- The bug report must include the following information:
- Requirement title
- Explanation of the need for the requirement
- Description of its use
- A use case description for complex requirements
- Implementation resources the company is willing to provide
- Companies submitting requirements must acknowledge that they will support the implementation of the requirement.
- The participants of the Working Group 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.
- If a requirement wins the consensus of the Working Group 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 "Working Group 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.
- If a requirement wins the consensus of the Working Group 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.
- If a requirement does not win the consensus within the Working Group as needed to be implemented in MeeGo, it will remain tagged as "Working Group Requirement" in bugs.meego.com for a specific amount of time, to be decided by the Working Group. 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 Working Group:
- Contact the Working Group Chair for the specific MeeGo vertical, who will introduce you to the Working Group, help integrate you/your team with the Working Group and project team of the MeeGo vertical, direct you to the Working Group mailing list and wiki, and provide you with information about regular meetings, ongoing activities, etc.
- MeeGo IVI Working Group Chair – Rudolf.Streif (at) linuxfoundation.org - rudolfstreif
- MeeGo Handset Working Group Chair – Ibrahim (at) linuxfoundation.org - ibrahim
- You need to identify and assign:
- A representative from your organization that will participate in the Working Group of interest to you. The representative will be bringing the requirements from your company and driving them to acceptance within the Working Group 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 Working Group:
If you are interested in a MeeGo Working Group 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 Working Groups
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 Working Group 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 Working Group Home Page http://wiki.meego.com/in-vehicle