Mobile & Embedded Community Governance

Introduction

This document provides information on the structure, policies, goals and objectives of the Mobile & Embedded Community and sets forth how the community will govern itself through a common set of policies and procedures. The Mobile & Embedded Community is composed of individuals collaborating in the community on software projects to produce secure, robust and technologies and platforms.

Mobile & Embedded Community Charter

The charter of the community is to establish a thriving community that enables and empowers developers to collaborate and innovate, driving the evolution and adoption of the Java ME platform for mobile and embedded devices.

Founding Principles

The Mobile & Embedded Community is founded on these four principles that are characteristic of open source development:

• Transparency
  Projects are open to everyone who becomes a member of the community.
• Participation
  People are enabled to work together to create and innovate for the betterment of the community.
• Compatibility
  Promote existing standards, align with the Java Community Process program, and preserve the Java technology specifications.
• Engineering Excellence
  Define processes and guidelines that facilitate the creation of high quality, deployable solutions.

These principles were chosen to enable the Mobile & Embedded Community to grow rapidly, develop high quality and innovative technology, and accelerate the development of next generation applications for mobile and other market segments.

The Structure

This diagram depicts some of the key roles and relationships in the community. These roles are described on this page, with additional details found on the Recommended Project Management and the Community Participation Handbook documents.

Governance Board

Purpose

The main purpose of the Mobile & Embedded Community Governance Board is to maintain the health and communication channels within the community while supporting its goals, nourishing its growth, overseeing all the affairs of the community, and facilitating the alignment with the community's established principles and objectives.

Governance Board responsibilities include:

• Ensure all contributions represent the values of the majority of the community and not simply the views of a small group.
• Ensure collaboration and peer review across the community.
• Manage and resolve conflicts, governance, branding and other non-technical issues related to the projects in the community.
• Amend the governance model of the community when needed.
• Ratify processes and procedures to be used by the entire community.
• Support and empower community participation for all projects.
• Approve project graduation against published criteria.

Intervention

The Governance Board reserves the right to intervene if projects do not adhere to the Founding Principles and the Charter of the Mobile & Embedded Community. The intervention can include blocking project releases or labeling them deficient based on objective evaluation in areas such as the following:

• Technology compliance
• Policy adherence
• Community input

Governance Modification

Modifications to the governance can only be undertaken by the Governance Board after being proposed by a member of the board. Any additions, deletions or modifications can be undertaken only after a high threshold of acceptance of a two-thirds majority of the Governance Board members and not with a simple majority of 51% of the active board members.

Members

The Governance Board is composed of five members each with a one year term. Sun appoints two of its employees as members for the two permanent seats on the Governance Board. The third member will be appointed by Sun within the first 6 months and will be a non-Sun member of the community. The fourth and fifth members are elected from the membership of the Mobile & Embedded Community. The Governance Board is formed of equal members with no hierarchy. One of the board members is selected as the Governance Board chair-person to provide organizational support for all meetings. The chair-person is responsible for overseeing of the agenda, potential actions to be taken by the Governance Board, and meeting logistics including publishing of the minutes and any other related information about the meeting itself.

Terms of Membership and Expiry

Although Governance Board members each serve one-year terms, each member shall continue to serve until either a successor is appointed, or upon early resignation, removal, or death. There are no restrictions on the number of terms a member can be in office. Members appointed during the one year term to fill a vacancy serve until the completion of that year.

Suspension, Resignation, and Removal

Suspensions and removals from the Governance Board require an approval with a two-thirds majority vote of all the Governance Board members. A member may resign at any time upon written request to the Governance Board. A Governance Board member must be immediately removed from the Governance Board upon the termination of the membership. The Governance Board has the responsibility to fill any vacancy before its next meeting adhering to the procedures described in this document.

Good Standing

A Governance Board member is deemed in good standing and eligible to vote on issues coming before the board if the member has attended, either in person or over a voice or video connection, a minimum of three of the last four board meetings, assuming there have been four meetings.

Quorum

A quorum of at least two thirds majority of the active board members is required for a meeting.

Meetings, Locations, and Voting

Governance Board meetings are designated by the Governance Board to be held in any location where a member is able to host it and provide logistical support. Meetings may be rotated, if necessary, so different members are able to host the meetings. Notifying all other Governance Board members at least seven calendar days before an upcoming meeting is highly preferred, although on rare occasions this might not be possible. Within the meeting notification mechanism, the Governance Board chair-person must identify all agenda items to be discussed and potential actions to be undertaken by the Governance Board. No Governance Board member can intentionally be excluded from the Governance Board meetings and all members must receive notice of the meeting as specified here. At each meeting, either personal, voice or electronic voting is permitted. No voting or action may be taken or approved by the Governance Board that is outside the stated purpose and duties set forth this document.

Initial Governance Board Membership

The initial Governance Board is as follows:

• Roger Brinkley (Sun appointed seat)
• Sue Abellera (Sun appointed seat)

Roles and Responsibilities

The meritocracy model upon which the community is based requires that roles and responsibilities are earned and achieved depending upon an individual's recognized contributions, current activity, and demonstrated commitment to the community. In addition to the following roles and responsibilities which are recognized by the community, project level roles can be created optionally as desired by the project's owner.

• Member   A java.net registered individual who shows interest in the community. A member participates in the community through general discussion areas and may contribute to the projects by providing feedback. It is a voluntary decision to become a member and there are no approvals required.


• Contributor   Also termed an Observer in the java.net domain. These are members who contribute to the community with design guidelines, architecture suggestions, white papers on related topics, bug submissions, and so forth, and not necessarily with source code contributions. It is a voluntary decision to become a Contributor and there are no approvals required. Integration of contributor contributions is at the discretion of the module owner or project owner and is an iterative, communicative process.


• Committer   This role is the equivalent of the Developer role in the java.net domain and is granted by the module or project owner. A contributor who is given write access to the code repository is a committer. Committers get committer rights on a project basis and must be approved as a committer for each project for which they desire to gain write access to the code repository.

  Note - The committer roles are not permanent and whether a member retains these roles depends on but is not limited to the following factors: frequency of contributions, quality of contributions, length and quality of commitment to the community, and so forth. All committer roles will be reviewed annually on November 1.



• Module Owner   A module owner is a committer who is in good standing and as the name signifies owns one or more modules. Module owners are appointed by the project owner(s). Module owners can nominate and approve committers for the modules they own. A module is defined as any significant sub-component of a project.


• Project Owner   This is role is assumed by one or more individuals who propose the creation of a project in the community. The project owner may later create the PMC for that project and nominate its members. The project owner or the PMC controls the project as a whole. It is a voluntary decision to become a project owner and there are no approvals required.


• Voting Member   Project Owners of graduated projects qualify to be a Voting member. Only voting members can nominate potential Governance Board members.


• Community Leader   Responsible for the primary management of the community.
• Community Editor  Responsible for the content on the community pages.
• Community Evangelist   Responsible for encouraging and fostering community participation from a technical perspective.
• Community Program Manager   Manages the project development and life cycle processManages the development and life cycle progess as well as providing general oversight to the execution of community projects.
• Board Member   Individuals who get appointed or elected to the Governance Board are board members. Board members have to be active members of the community.

Type of Projects

Java Platform Projects

Building blocks for Java ME runtime platforms VM, configurations, profiles, optional packages, etc.

Java Tools Projects

Java ME development tools, utilities, libraries, etc.

Java Application Projects

Java ME applications based on either Midlet or Xlet paradigms for mobile, TV, telematics, printers, etc. as well as programs that run on top of the Java platform (not middleware or code bases that overlap existing JCP standards).

Creating a New Project

To create a new project in the Mobile & Embedded Community, one must follow the instructions in the Request a Project area on the java.net web site. Include as much detail as possible when requesting a project. The request is then submitted to the community leader for consideration.

Before trying to create a new project, browse the current list of projects to see if your project is unique. If a similar effort is already underway you should feel free to join that effort. Maintaining compatibility and focus in accordance with the Mobile & Embedded Community Founding Principles and Charter is the key to obtaining project approval. A project submitted without a license selected or a sufficient project description is deferred until these details are provided. Approved project requests are placed in the incubator.

Incubator

The incubator concept exists to demonstrate the viability of an individual project. The Governance Board and the community leader actively encourage and work with the project owner while it is in the incubator stage regarding the community approval and graduation of the project. The goal is to take it out of the incubator and into a formal Mobile & Embedded Community project. Once out of the incubator, it is then possible to do formal releases.

The incubator entry criteria are as follows:

• A one page description of the project mission, and its objectives and goals.
• A legitimate contact point.
• Description of likely participants.
• Content such as source code, a white paper, or a design document are desired but not required.
• Distribution under an Open Source Initiative (OSI) approved license.
• Alignment with the Mobile & Embedded Community Charter and JCP to preserve defined Java APIs.
• All contributors to Java Platform projects must submit a signed Contributor Agreement (SCA) prior to submission of their first contribution.

Graduating From the Incubator

To graduate from the incubator to official Mobile & Embedded Community project status, a project must meet the following criteria:

• Clearly demonstrate alignment with the Founding Principles and Community Charter.
• Transparency   The project has design documentation, code availability, and an open participatory model.
• Quality   It is feature complete with reasonable quality, judged by looking at how many of the following types of components and characteristics it might have:
  • Unit tests and documentation on building and running the software.
  • Source code qualities such as modularity, readability, and comments.
  • Buildable and runnable.
• Compatibility requirements   It promotes existing standards, aligns with the Java Community Process (JCP)™ program, and preserves previously defined Java™ APIs.
• Meet the necessary legal requirements.
• Gather community support.

When completing the graduation process, the voice of the community is monitored through the general interest mailing list for approximately two to three business days. This alias is also used to announce pending graduation approval.

Abandoned Projects

A project having no activity for a period of 90 days is considered an abandoned project. Once a project is abandoned, an email is sent to the project's owner(s) and the interest aliases announcing that the project is considered abandoned and might be deleted in 10 business days. If no objections are raised, the project is removed from the Mobile & Embedded Community. If there are objections, the objections must have a reason as to why the project should not be deleted and a plan to get the project active again.

Voting

Governance Board Member Nomination and Election Mailing List

There is a mailing list created and maintained by the community leader for those interested in discussions surrounding Governance Board membership, nomination, and election. The call for nominations and election will be initiated by the Governance Board. Voting members of the community are automatically enlisted in this mailing list and can monitor and participate in the discussions surrounding Governance Board membership, nomination, and election. The community leader acts as the moderator for this mailing list.

Voting on Community-Level Versus Project-Specific Matters

A community-level vote can be conducted for matters regarding processes and procedures affecting the overall community. For processes and procedures affecting a single project or group of related projects, the involved project owner(s) are free to either conduct a poll or decide within themselves.

Project Level Management

There are community recommended project managment guidelines but projects are free to manage as they wish.

The Role of Sun Microsystems

Sun Microsystems pledges to participate in the Mobile & Embedded Community as partner with the other legal entities participating in the community, and further, to abide by the same rules for participation as everyone else. In return, the other community members agree to abide by any legal constrains regarding the development, hosting and redistribution of products within the designated community systems.

Sun Microsystems pledges to help define and support the community goals by assisting with the following:

• Dispersing and implementing the technologies
• Supporting experimentation and innovation within the technologies
• Providing a common platform for all tools
• Promoting the creation of custom components that support vertical implementations