Symbian Foundation Council Charters

From Symbian Developer Community

The Symbian Foundation Councils exist to support the foundation community and grow the competitiveness of the Symbian platform by:

Identifying high-level market, user and technical requirements;
Soliciting contributions that address those requirements;
Coordinating community contributions into regular platform releases; and
Providing transparency for all community members regarding future platform developments.

Together the councils constitute the decision-making bodies governing the contents and specifications of foundation software releases. The councils also act as caretakers and improvers of the foundation community’s collaboration process.

This document describes the collective and individual functioning of the councils. Each council has its own distinct set of responsibilities, which together are designed to complement each other and provide coordinated support for foundation contributors and community members. The responsibilities of each council are as follows:

The Feature and Roadmap Council invites proposals for contributions from the community and seeks to coordinate new contributions into a unified platform (or tools) roadmap;
The Architecture Council invites and reviews technical solutions for new contributions in order to ensure the architectural integrity, backward compatibility and fitness-for-purpose of enhancements to the platform;
The User Interface Council invites and reviews descriptions of new user interface elements and develops guidelines to help ensure high quality device user experiences;
The Release Council coordinates the integration of contributions into stable and timely platform and tools releases.

It is expected that many improvements to council operations will be suggested during the day-to-day activities of the community. Changes to this Charter document and to the processes of the councils should be made to reflect these suggestions where appropriate.

1 Councils process overview
2 Council operations
3 Feature and Roadmap Council Charter
4 Architecture Council Charter
5 User Interface Council Charter
6 Release Council

Councils process overview

Figure 1 below presents an overview of the flow between the Councils and the broader community.

Figure 1: Overview of Councils process

The process, with each step corresponding to a number in Figure 1, is as follows:

A potential contributor who wants to propose a new feature for a platform release prepares a Development Proposal. This describes the market needs and benefits of the proposed development, the proposed timing of deliverables, key architectural features and any dependencies on third-party intellectual property.
The Feature and Roadmap Council reviews the Development Proposal, provides feedback and holds a vote to gauge support. If a majority of the council supports the proposal, it is classed as Approved and added to the scope of the relevant platform release(s). Otherwise it is classed as Rejected. The development described in a Rejected proposal may still be contributed to the foundation but shall not be included in the scope of an official platform release.
The Feature and Roadmap Council publishes a Platform Roadmap describing the contents of future releases.
Following the approval of a Development Proposal, the contributor prepares a Technical Solution Description, describing the high-level design for the development, including architectural impact, security considerations and any proposed additions or changes to APIs.
The Architecture Council reviews the Technical Solution Description, provides feedback and holds a vote to gauge support. If a majority of the council supports the proposal, it is classed as Approved. Otherwise, it is classed as Rejected.
If the proposed development has a significant impact on the user experience, the contributor is asked to prepare a UI concept proposal describing the high-level user interface design.
The User Interface Council reviews the UI Concept Proposal, provides feedback and holds a vote to gauge support. If a majority of the council supports the proposal it shall be classed as Approved. Otherwise the proposal shall be classed as Rejected. Developments corresponding with Rejected UI Concept Proposals shall be removed from the scope of the relevant platform release(s). Upon rejection of a UI Concept Proposal, the User Interface Council Chair shall notify the other council chairs.
Where a Development Proposal has been approved for inclusion into a given platform release, the relevant Release Project Manager shall work with the contributor to obtain information regarding the scheduling of the proposed contributions. The Release Project Manager shall use this information to prepare (or update) the Release Project Plan, highlighting the status and risks associated with each deliverable in the release.
The Release Council reviews the Release Project Plan, provides feedback and votes to Approve or Reject the plan. Where a majority supports the plan, it is classed as Approved, otherwise it is classed as Rejected. Accordingly, the council may issue recommendations to the Feature and Roadmap Council or Architecture Council to make modifications to the Roadmap or Architecture if necessary.

The chapters below describe the practices and procedures common across all councils, the decisions that each council is responsible for, and the documents that each council publishes. It is expected that each council may in turn supplement this information with its own detailed process document(s).

Council operations

Council chairs

Each council shall have a chair appointed by the foundation’s Executive Director. The chair shall be a member of the foundation staff. The chair for each council shall be responsible for ensuring the council follows the guidelines in this document.

Council members

A Council Member is a company that is entitled to nominate representatives to participate in council discussions. A company becomes a Council Member either through a) exercising its right to a council seat as an Appointing Member of the foundation, or else b) by being invited to become a member of one or more councils by the Board of Directors.

Council representatives

Each Council Member company shall nominate 2 persons to each council of which it is a member: a primary representative and a deputy representative. Both the primary representative and the deputy may participate in online discussions, teleconferences and face-to-face meetings relating to the council.

Council representatives should have sufficient knowledge of the Symbian Foundation platform and its industry context to be able to make valuable and knowledgeable contributions to council activities.

Council meetings

The chair of each council shall organize council meetings.

Meetings, reviews of proposals and votes may take place in person, via teleconference, via online meeting or via email. Council meetings shall in general take place not less frequently than monthly.

Council chairs shall collectively take care to coordinate the scheduling of meetings in order to allow participation in more than one council meeting where necessary.

The chair shall distribute the agenda and supporting documents to all members not less than 10 working days before a meeting or teleconference.

Attendance and participation

Each council representative or deputy shall participate wherever possible in all conference calls, online or face-to-face meetings and votes of their respective council. The chair shall record meeting attendance and voting participation and may report this information from time-to-time to the Executive Director or Board of Directors.

Submission of items for a council consideration

Members of the community wanting to propose items for consideration should do so by approaching the council chair, a council representative, or the Technology Manager for the relevant technology domain. The chair may nominate a Technology Manager to correspond with the community member in preparing a proposal for submission.

Voting on items requiring approval

Proposals requiring a council vote shall be distributed not less than 10 working days before voting is required to be complete. The chair shall indicate to representatives the date by which votes must be registered and the means by which each member representative should register their vote.

Each council member company has precisely one vote. The council chair shall not vote.

Approval of all items is via a simple majority vote unless otherwise indicated below. Rejected proposals may be resubmitted following revision. Council members are encouraged to give reasons for rejection to allow the author to address them.

Quorum

At least two thirds of the members of a council must participate in a vote for its outcome to be considered valid. “Participate” means to register a vote in person at a face-to-face meeting, via a conference call, or via an electronic vote.

Publication of meeting records and votes

The council chair is responsible for ensuring that minutes from all council meetings and teleconferences, including the results of votes, are published to the Symbian Foundation community.

Feature and Roadmap Council Charter

Objectives of the Feature and Roadmap Council

The chief objectives of the Features and Roadmap Council are:

To ensure that the foundation platform provides a competitive set of features;
To identify additional features for which there is a market need and agree on how best to collaborate in order that the platform may provide those features; and
To ensure that important feature additions are aligned for delivery in platform releases in a timely and coherent manner.

Key activities of the Feature and Roadmap Council

The Feature and Roadmap Council acts as a point of contact and coordination for significant contributions to the foundation. The Feature and Roadmap Council also provides guidance for future contributions through the publication of probable ‘themes’ of future platform releases.

The main activities the Feature and Roadmap Council undertakes in support of these roles are as follows:

Review of and voting on Development Proposals made by community members;
Approval and publication of the Foundation Roadmap;
Discussion of critical gaps and new feature ideas in relation to the foundation platform; and
Publication to the community of proposed ‘themes’ for future releases;
Interaction with other councils for the purposes of alignment, thereby ensuring that planned contributions follow a smooth process: from the submission of a Development Proposal to its inclusion in a release.

Decision-making responsibilities of the Feature and Roadmap Council

Table 1 below summarizes the decisions and approvals that are the responsibilities of the Feature and Roadmap Council.

Area	Responsibilities of the Feature and Roadmap Council
Feature and Roadmap Council Charter	The Feature and Roadmap Council may propose modifications to its Charter. Any council representative may propose a modification. Proposed modifications must be supported by a majority vote from council representatives. Where proposed modifications are supported by a majority, the modifications shall be proposed to the Foundation Board of Directors for approval. Where proposed modifications are not supported by a majority, the proposed modifications shall be rejected.
Release Themes	The Feature and Roadmap Council may decide themes for future platform releases. Any council representative may propose a theme. Candidate themes will be approved or rejected by the Feature and Roadmap Council via a simple majority vote. Approved themes shall be communicated via the Platform Roadmap.
Development Proposals	The Feature and Roadmap Council shall approve Development Proposals. Any community member may make a Development Proposal for inclusion in a target release. The Feature and Roadmap Council approves Development Proposals via simple majority vote.
Platform Roadmap	The Feature and Roadmap Council shall approve for publication the Platform Roadmap. Modifications to the published Platform Roadmap may be proposed by any Feature and Roadmap Council representative, any other council, or any community member via a Feature and Roadmap Council representative. Modifications shall be approved via a simple majority vote.

Table 1: Responsibilities of the Feature and Roadmap Council

Documents under Feature and Roadmap Council change control

The following documents shall be published by the Feature and Roadmap Council via the Symbian Foundation website and maintained under change control of the Feature and Roadmap Council.

Unless otherwise stated, modifications to any of these documents may be proposed by any member of the community, provided he/she has the support of at least one Feature and Roadmap Council representative; modifications require a simple majority to be approved.

Document	Description
Development Proposal Template	The template to be used as the basis for Development Proposals by community members.
Platform Roadmap	The document describing the content of future platform releases.
Feature and Roadmap Council Procedures	The document describing detailed processes and procedures (such as meeting details, document archives, etc.) for the Feature and Roadmap Council. Where a change to procedures represents a proposed change to the set of decisions for which the Feature and Roadmap Council is responsible, this shall be considered a change to the charter and must be reflected in this document accordingly.

Table 2: Documents under Feature and Roadmap Council change control

Architecture Council Charter

Objectives of the Architecture Council

The chief objectives of the Architecture Council are to:

Identify and resolve important architectural issues;
Ensure that contributions to new versions of the foundation platform maintain architectural integrity and the backward compatibility promise;
Agree technical standards for new platform versions including the choice of build environment, reference execution environments and the standard compatibility test suite;
Ensure that packages have suitable owners; and
Agree changes to the collaboration process and recommend changes to the supporting infrastructure that will promote the prosperity of the entire community.

Key activities of the Architecture Council

The main activities undertaken by the Architecture Council in support of these objectives are as follows:

Evaluating architecturally significant changes to the Symbian Foundation Platform and associated developer tools, including architecture changes and public API changes;
Evaluating and agreeing technical standards for new platform versions, including the choice of build environment, reference execution environments and the standard compatibility test suite;
Agreeing package owners and package ownership practices; and
Reviewing proposed changes to collaboration processes and supporting tools.

Decision-making responsibilities of the Architecture Council

Table 3 below summarizes the decisions and approvals that are the responsibilities of the Architecture Council.

Area	Responsibilities of the Architecture Council
Architecture Council Charter	The Architecture Council may propose modifications to its Charter. Any council representative or the Chief Architect may propose a modification. Proposed modifications must be supported by a majority vote from council representatives. Where proposed modifications are supported by a majority, the modifications shall be proposed to the Foundation Board of Directors for approval. Where proposed modifications are not supported by a majority, the proposed modifications shall be rejected.
Architecture Model Structure	The Architecture Council approves modifications to the Architecture Model Structure. Any community member may propose a modification. The Architecture Council approves modifications via simple majority vote.
Collaboration Process	The Architecture Council may propose modifications to the Collaboration Process. Any council representative or the Chief Architect may propose a modification. Proposed modifications must be supported by a majority vote from council representatives. Where proposed modifications are supported by a majority, the modifications shall be proposed to the Foundation Board of Directors for approval. Where proposed modifications are not supported by a majority, the proposed modifications shall be rejected.
Compatibility test suite	The Architecture Council approves the specifications of the Compatibility test suite for a given platform release. Any council representative or the Chief Architect may propose a modification. The Architecture Council approves modifications via simple majority vote.
Extensions to the public API	The Architecture Council approves extensions to the Public API. Any package owner may propose an extension to the Public API. The Architecture Council approves modifications via simple majority vote.
Package ownership transfers	The Architecture Council approves transfers of package ownership. Any council representative or the Chief Architect may propose a transfer. The Architecture Council approves transfers via simple majority vote.
Public API backward compatibility break	The Architecture Council approves Public API backward compatibility breaks. Any package owner may propose a compatibility break. The Architecture Council approves breaks via simple majority vote.
Public API concessions	The Architecture Council approves Public API concessions. Any OEM may propose a Public API concession. The Architecture Council approves concessions via simple majority vote.
Symbian Foundation reference execution environments	The Architecture Council approves the supported Symbian Foundation reference execution environment(s). Any community member may propose a reference execution environment. The Architecture Council approves the adoption of a reference environment via simple majority vote.
Technical Solution Descriptions	The Architecture Council approves Technical Solution Descriptions. Any community member may make a Technical Solution Description. The Architecture Council approves Technical Solution Descriptions via simple majority vote.
UI Council decisions	The Architecture Council may ratify or veto UI Council decisions. The UI Council shall inform the Architecture Council of its decisions in relation to UI Concept Proposals. Any member of the Architecture Council or the Chief Architect may propose a veto. Vetoes are upheld via a simple majority vote.

Table 3: Responsibilities of the Architecture Council

Documents under Architecture Council change control

The following documents shall be published by the Architecture Council via the Symbian Foundation website and maintained under change control of the Architecture Council.

Unless otherwise stated, modifications to any of these documents may be proposed by any member of the community, provided he/she has the support of at least one Architecture Council representative; modifications require a simple majority of the Architecture Council to be approved.

Document	Description
Architecture Principles	This document describes the architectural principles and standards that should be observed when contributing to the Symbian Foundation Platform. The document also describes the way in which Symbian Foundation Platform software is modelled and defines many of the terms used in other documents.
System Definition XML Schema	Each package is required to include a system definition XML file that conforms to the schema described by this document. Only the schema is under Architecture Council change control – the XML files that follow the schema are controlled by their respective package owners. The package system definition file describes the collections and components in the package, with attributes at the package, collection or component level. An example of a package level attribute is the Technology Domain. An example of a component level attribute is test versus production code.
Technical Solution Description Template	This document is an annotated template for technical solution descriptions.
Device compatibility and certification	This document describes what is meant by device compatibility, supporting Symbian Foundation processes, and the steps that OEMs need to take to certify their devices as compatible.
Reference execution environment selection	This document defines what is meant by ‘Hardware Reference Platform’ (HRP) and how HRPs are selected by the foundation community.
Coding Conventions	The key C++ coding conventions that contributors to platform packages should adhere to. This does not apply to tools packages.
Contribution Process	The high level process that governs how contributions are brought into the Symbian Foundation-managed code lines, including rules for package owners and other contributors, workflow and communication flows.
Public API Change Control	The process for proposing public API breaks, deprecation of APIs and extensions/additions to APIs.
Error Management	The high level process by which Symbian Foundation Platform software errors should be reported, managed, and resolved.
Testing and releasing	The high level processes by which Symbian Foundation personnel and community members collaborate to test and harden platform releases.
Reference Execution Environment Selection Process	Generic requirements for the Reference Execution Environments and a description of the selection process.
Foundation Operational Environment	The choice of systems and tools used by the Symbian Foundation where decisions have a significant impact on package owners, such as collaboration tools: SCM, error reporting, testing framework, build framework, reference environments and compilers.
Good Community Behavior	The stated principles and good community behaviour “expectations” for the key roles of the Symbian Foundation community.
System model structure	Files that encode the allocation of packages to architecture models (either device model or tools model) and to layers within each model. The organisation of components into collections within packages is not change controlled.
Package owner list	Lists the package owning organisation for each package. There is also a named individual (email address) but this can be changed freely by the package owner.
Architecture Council Procedures	The document describing detailed processes and procedures (such as meeting details, document archives, etc.) for the Architecture Council. Where a change to procedures represents a proposed change to the set of decisions for which the Architecture Council is responsible, this shall be considered a change to the charter and must be reflected in this document accordingly.

User Interface Council Charter

Objectives of the User Interface Council

The chief objectives of the User Interface Council are to:

Encourage and contribute to a User Experience-driven evolution of the foundation platform; and
Drive the creation of a open and flexible user interface framework for the foundation platform allowing members to differentiate in their delivery of compelling user experiences.

Key activities of the User Interface Council

The User Interface Council acts as a point of coordination in the design and contribution of platform elements that have an impact on the user experience.

The main activities the User Interface Council undertakes in support of its objectives are as follows:

Review of User Interface Concept Proposals for potential contributions to the foundation platform;
Review and publication of user interface design guidelines;
Review of the UI & Graphics Technology Domain roadmap;
Establishing working groups to drive improvements or solve issues relating to user interfaces and usability; and
Collaboration with the Feature and Roadmap Council to provide input on future requirements and themes.

Decision-making responsibilities of the User Interface Council

Table 4 below summarizes the decisions and approvals that are the responsibilities of the User Interface Council.

Area	Responsibilities of the User Interface Council
User Interface Council Charter	The User Interface Council may propose modifications to its Charter. Any council representative may propose a modification. Proposed modifications must be supported by a majority vote from council representatives. Where proposed modifications are supported by a majority, the modifications shall be proposed to the foundation Board of Directors for approval. Where proposed modifications are not supported by a majority, the proposed modifications shall be rejected.
User Interface Guidelines	The User Interface Council approves the User Interface Guidelines for the platform. Any community member may propose modifications to the User Interface Guidelines. Modifications to the User Interface Guidelines will be approved or rejected by the User Interface Council via a simple majority vote.
User Interface Concept Proposals	The User Interface Council approves UI Concept Proposals. Any potential contributor may be required to make a UI Concept Proposal for a development targeted at inclusion in a future platform release. The User Interface Council approves UI Concept Proposals via simple majority vote. Approval of a UI Concept Proposal shall signify that the relevant contribution may form part of a platform release.
User Interface Enablers Backlog	The User Interface Council shall approve and publish a set of requirements for User Interface Enablers as a means of inviting relevant contributions. Any community member may propose modifications to the list of User Interface Enablers Backlog. The User Interface Council shall review proposed modifications provided one or more sponsors for the modifications exist in the User Interface Council. Modifications to the User Interface Enablers Backlog will be approved or rejected by the User Interface Council via a simple majority vote.

Table 4: Responsibilities of the User Interface Council

Documents under User Interface Council change control

The documents listed in Table 5 shall be published by the User Interface Council via the Symbian Foundation website and maintained under change control of the User Interface Council.

Unless otherwise stated, modifications to any of these documents may be proposed by any member of the community, provided he/she has the support of at least one User Interface Council representative; modifications require a simple majority of the User Interface Council to be approved.

Document	Description
User Interface Style Guide	The document describing the overall design philosophy and user interface guidelines for foundation applications and user experience.
User Interface Concept Proposal Template	UI Council issues and approves updates by majority vote.
User Interface Council Procedures	The document describing detailed processes and procedures (such as meeting details, document archives, etc.) for the User Interface Council. This document also details reasons for possible rejection of User Interface Concept Proposals. Where a change to procedures represents a proposed change to the set of decisions for which the User Interface Council is responsible, this shall be considered a change to the charter and must be reflected in this document accordingly.

Table 5: Documents under change control of the User Interface Council

Release Council

Objectives of the Release Council

The chief objectives of the Release Council are:

To ensure that the foundation roadmap is delivered to high quality in a timely manner;
To ensure the compatibility and stability of each platform release in order to maintain a reliable and trusted platform for the community;
To support development projects in the community and help them deliver successfully; and
To act as a review body for the foundation release model.

Key activities of the Release Council

The Release Council exists to support the reliable delivery of robust platform releases. It acts as a point of coordination for project management and risk mitigation and ensures community-wide transparency regarding development and release plans. It also acts as an escalation point for project-related issues.

The main activities the Release Council undertakes in support of its objectives are:

Review of project plans and project plan updates;
Review of project milestone status;
Review and guidance on issues escalated by project managers or other community members; and
Review and proposal of mitigating actions, such as the removal of a planned development from a release or a change to a release schedule.

Decision-making responsibilities of the Release Council

Table 3 below summarizes the decisions and approvals that are the responsibilities of the Release Council.

Domain	Responsibilities of the Release Council
Release Council Charter	The Release Council may propose modifications to its Charter. Any council representative may propose a modification. Proposed modifications must be supported by a majority vote from council representatives. Where proposed modifications are supported by a majority, the modifications shall be proposed to the foundation Board of Directors for approval. Where proposed modifications are not supported by a majority, the proposed modifications shall be rejected.
Release model	The Release Council approves minor modifications to the foundation release model. The Release Council may propose major modifications to the foundation release model to the Board of Directors. Any community member may propose changes for consideration by the Release Council. The Release Council will decide to support or reject proposed changes by majority vote.
Project Plans	The Release Council approves Release Project Plans and modifications to Release Project Plans. The foundation Release Project Manager presents projects plan to the Release Council for approval by majority vote.
Recommendation to omit feature from Platform Release	The Release Council approves omissions from a platform release. Foundation project managers may propose omissions. If no other suitable solution is available the Release Council will vote on the omission. If a majority supports the proposed omission it is approved and other councils are informed.
Timing of Platform Releases	The Release Council may approve minor modifications to the schedule or timing of a platform release. If a feature is critical, the Release Council may recommend a small delay of the platform release via majority vote, or give permission to integrate an additional feature later. This will be communicated to the foundation Executive Director who will seek ratification from the foundation Board of Directors ratification if deemed necessary.
Milestones of Projects	The Release Council approves milestone passes for release projects. Foundation project managers may propose milestone approvals. The Release Council approves if a majority of member representatives support.

Table 6: Responsibilities of the Release Council

Documents under Release Council change control

The documents listed in Table 7 shall be published by the Release Council via the Symbian Foundation website and maintained under change control of the Release Council.

Unless otherwise stated, modifications to any of these documents may be proposed by any member of the community, provided he/she has the support of at least one Release Council representative; modifications require a simple majority of the Release Council to be approved.

Document	Description
Foundation Release Model Description	Describes the model for releases of the Symbian Foundation Platform in terms of frequency, granularity, deployment method etc. The document is authored by the Foundation Head of Delivery Management or a nominated foundation staff member. Minor revisions are approved for publication by majority vote of the Release Council. Major revisions are approved for publication by the Foundation Board of Directors.
Release Project Plan template	The generic template for use when monitoring the status of release projects.
Release Project Plans	Produced by Foundation Project Managers to summarize status and risks in relation to release projects.
Reporting Template for release projects	The templates used for progress and status reporting within release projects.
Release Council Procedures	The document describing detailed processes and procedures (such as meeting details, document archives, etc.) for the Release Council. Where a change to procedures represents a proposed change to the set of decisions for which the Release Council is responsible, this shall be considered a change to the charter and must be reflected in this document accordingly.

Table 7: Documents under change control of the Release Council

Retrieved from "http://developer.symbian.org/wiki/index.php/Symbian_Foundation_Council_Charters"

Comments

Category: Councils