Skip to content

GitLab

Last edited by Raj Kannan
Page history
This is an old version of this page. You can view the most recent version or browse the history.

Charter

Under Development

This document defines the OSDU Project Management Committee (PMC) goals, objectives, roles and responsibilities. Further, this document establishes the operating model for all Open Source OSDU Projects, as well as how the PMC will provide vision, leadership and governance for these OSDU PMC Projects, under governance of the OSDU Management Committee (OMC).

PMC Projects

The PMC governs software projects contributing to the development of the OSDU data platform under an Open Source Model.

PMC Goals & Objectives

The PMC is expected to ensure that:

  • All PMC Projects operate effectively by providing leadership to guide the Project's overall direction, and, by removing obstacles, solving problems, and resolving conflicts
  • All PMC Project charters, plans, technical documents, source code and reports are publicly available
  • All PMC Projects operate using open source rules of engagement: meritocracy, transparency, and open participation. These principles work together. In principle, anyone can participate in any aspect of a Project
  • All PMC Projects are supported by a healthy OSDU developer community. PMC works with OMC to champion the open source principles within the OSDU community
  • All PMC Projects deliver high quality products.
  • All PMC Projects deliver software products that can be licensed under Apache version 2.0
  • PMC Project reporting and communication to OMC, and subsequently to the OSDU community are done in a timely and effective manner

PMC Responsibilities

The PMC has the following responsibilities:

  • Providing the vision and leadership to guide the overall direction for all PMC projects, in a manner consistent with the OSDU roadmap and OSDU Reference Architecture principles
  • Providing assistance and support to the developers working on the Project by removing obstacles, solving problems, and resolving conflicts
  • Ensuring that substantive Project Charters are produced for each Project
  • Recommending new Projects to the OMC; All new projects are to be approved by the OMC
  • Establish the processes, metrics, measurements, and tooling needed to ensure the quality of delivered software products
  • Establish the process of choosing other open source components for software development
  • Ensuring that all development activities conform to any rules or processes outlined in the Project Charter
  • Working with the OMC to establish the processes and infrastructure needed for the project teams to be effective
  • Establishing the initial set of Project Committers (see definition below) for each new Project overseen by the PMC, and establishing the procedures consistent with the Project Charter for voting in new committers
  • Ensuring that Project plans are produced, and presented to the OMC
  • Ensuring that the Projects overseen by the PMC have enough contributors, and working to fill vacancies in roles; escalating to the OMC when there are not sufficient resources to achieve advertised delivery objectives
  • Producing "how to get involved" guidelines to help new potential contributors get started
  • Working with Project Committers to ensure in-bound contributions are made in accordance with the OSDU Intellectual Property Policies
  • Establishing a PMC release engineering and build process
  • Ensuring all Project development is done according to established release engineering and build processes in order to ensure that builds can be reliably produced on a regular and frequent basis from the master code base; builds in this context are intended to include not only code but also reports, documentation, and courseware
  • Ensuring all code is made available for download from the Project web site
  • Providing regular progress reports to OMC
  • Providing technical support to OSDU Developers bootcamps

PMC Roles

PMC Lead

  • The initial PMC Lead is selected by the OSDU OMC. The PMC Chair will serve a two-year term.

PMC Vice-lead

  • The PMC Vice-lead is elected by the OSDU membership. The PMC Vice-lead will serve a two-year term. However, PMC Lead and PMC Vice-lead will not be replaced at the same time but as a minimum there must be 9 months in between.

PMC At-Large Member

  • The remainder of the PMC will be made up from the Project Leads (see definition below). Initially, Project Leads will be selected by the PMC Lead and Vice-lead. Thereafter, Project Leads can be nominated by any other member of the PMC, and via or majority voting approved by all PMC members.

The work of the PMC is shared by the PMC members. All PMC members are expected to contribute actively. In particular, PMC members are expected to take responsibility for overseeing certain areas of work within a particular Project, and reporting to the PMC on these areas. Because of the diversity amongst individual projects, PMC members are not expected to maintain anything other than general currency with a Project that is outside their assigned technical areas.

Active participation in the user newsgroups and the appropriate developer mailing lists is a responsibility of all PMC members, and is critical to the success of the Project. PMC members are required to monitor the main Project mailing list, and the developer mailing lists for all Projects and components they are overseeing.

In the unlikely event that any member of the PMC becomes disruptive to the process, or ceases to contribute for an extended period, that member may be removed by unanimous vote of remaining PMC members. PMC members may resign at any time by delivering notice of their resignation to the PMC Lead.

PMC Project Governance

All PMC Projects are operated as meritocracies -- the more you contribute, and the higher the quality of your contribution, the more you can do.

Each PMC Project must identify, and make available on its web site, the requirements and prioritizations it is working against in the current release cycle. In addition, each PMC Project must post a release plan showing the date and content of the next major release, including any major milestones, and must keep this plan up to date.

When a new PMC Project is created, the PMC nominates a PMC Project Lead to act as the technical leader, and nominates the initial set of Project Committers for the Project. The PMC Project Lead is accountable to the PMC for the success of their PMC Project. The Committers of a PMC Project or component decide which changes may be committed to the master code base of a PMC Project or component respectively. The PMC defines the decision process, but that process must include the ability for Committers to veto the change. The decision process employed may change with the phase of development. Common decision processes include:

  • *Retroactive *- changes are proactively made by Committers but can be vetoed by a single Committer.
  • *Proactive *- for efficiency, some code changes from some contributors (e.g. feature additions, bug fixes) may be approved in advance, or approved in principle based on an outline of the work, in which case they may be committed first and changed as needed, with conflicts resolved by majority vote of the Committers of the Project or component, as applicable.
  • Three Positive - No code is committed without a vote; three +1 ('yes' votes) with no -1 ('no' votes or vetoes) are needed to approve a code change. Vetoes must be followed by an explanation for the veto within 24 hours or the veto becomes invalid. All votes are conducted via the developer mailing list associated with the PMC Project or component. Special rules may be established by the PMC for PMC Projects or components with fewer than three Committers.

The master copy of the code base must reside on the PMC Project web site where it is accessible to all users, developers and committers. Committers must check their changes and new work into the master code base as promptly as possible (subject to any check-in voting rules that may be in effect) in order to foster collaboration among widely distributed groups and so that the latest work is always available to everyone.

The PMC is responsible for establishing a release engineering and build process to ensure that builds can be reliably produced on a regular and frequent basis from the master code base, and made available for download from the Project web site. Builds in this context are intended to include not only code but also reports, documentation, and courseware.

Each Project is responsible for establishing test plans and the level of testing appropriate for the Project.

All development technical discussions are conducted using the development mailing lists. If discussions are held offline, then a summary must be posted to the mailing list to keep the other committers, and any other interested parties, Given the fluid nature of PMC Projects, organizational changes are possible. In particular, there may be a need to:

  • divide a PMC Project into components
  • divide a PMC Project into two or more independent PMC Projects
  • merge two or more PMC Projects into a single PMC Project.

In each case, the initiative for the change may come either from within the Project, or from the PMC; but the PMC must approve any change.

If a PMC Project wishes to divide into components, commit privileges are normally granted at the component level. Components are established and discontinued by the PMC. When the PMC creates a component, it appoints a Component Lead to act as the technical leader and names the initial set of Committers for the component. The Component Lead is designated as a Committer for the PMC Project, and represents the Component in discussions. Component committers do not participate in votes at the level of the PMC Project as a whole, unless they are also the Component Lead.

In cases where new PMC Projects are being created, either by splitting or by merging, the usual procedures for the establishment of a new PMC Project are followed. In particular, Contributors will not necessarily have the same rights after an organizational change that they enjoyed in the previous structure.

PMC Project Roles

PMC Project Contributor

There are a couple of types of Project Contributors.

  • Users are the people who use the output from the Project. Output will typically consist of software in form of extensible frameworks and exemplary tools. Software in this context means intellectual property in electronic form, including source and binary code, documentation, courseware, reports and whitepapers.

  • Users who contribute software, documentation, or other materially useful content become developers. Developers are encouraged to participate in the user newsgroup(s), and should monitor the developer mailing list associated with their area of contribution. When appropriate, developers may also contribute to development design discussions related to their area of contribution. Developers are expected to be proactive in reporting problems in the bug tracking system.

PMC Project Committer

Developers who give frequent and valuable contributions to a Project, or component of a Project (in the case of large Projects), can have their status promoted to that of a "Committer" for that Project or component respectively. A Committer has “write access” to the source code repository for the associated Project (or component), and gains voting rights allowing them to affect the future of the Project (or component).

In order for a Developer to become a Committer on a particular Project (overseen by the PMC), another Committer for the same Project (or component as appropriate) can nominate that Developer or the Developer can ask to be nominated. Once a Developer is nominated, the

Committers for the Project (or component) will vote for a PMC-designated voting period, and that period shall be no less than one week. If there are at least 3 positive votes from different OSDU member organization representatives other than the Developer’s organization and no negative votes within the voting period, the Developer is recommended to the PMC for commit privileges. The PMC may waive the 3 vote minimum requirement in exceptional cases (e.g., there are fewer than 3 active committers on the project). If the PMC also approves, and the Developer signs the appropriate Committer agreements established by the PMC, the Developer is converted into a Committer and given write access to the source code and/or web repository for that Project (or component). Becoming a Committer is a privilege that is earned by contributing and showing discipline and good judgment. It is a responsibility that should be neither given nor taken lightly.

At times, Committers may become inactive for a variety of reasons. The decision making process of the Project relies on active committers who respond to discussions and vote in a constructive and timely manner. The PMC is responsible for ensuring the smooth operation of the Project. A Committer who is disruptive, does not participate actively, or has been inactive for an extended period may have his or her commit status revoked by the PMC.

Active participation in the user newsgroup and the appropriate developer mailing lists is a responsibility of all Committers, and is critical to the success of the Project. Committers are required to monitor and contribute to the user newsgroup.

Committers are required to monitor the mailing lists associated with all Projects and components for which they have commit privileges. This is a condition of being granted commit rights to the Project or component. It is mandatory because committers must participate in votes (which in some cases require a certain minimum number of votes) and must respond to the mailing list in a timely fashion in order to facilitate the smooth operation of the Project. When a Committer is granted commit rights, they will be added to the appropriate mailing lists. A Committer must not be unsubscribed from a Developer mailing list unless their associated commit privileges are also revoked.

Committers are required to track, participate in, and vote on, relevant discussions in their associated Projects and components. There are three voting responses: +1 (yes), -1 (no, or veto), and 0 (abstain).

Committers are responsible for proactively reporting problems in the bug tracking system, and annotating problem reports with status information, explanations, clarifications, or requests for more information from the submitter. Committers are responsible for updating problem reports when they have done work related to the problem.

PMC Project Lead

Ideally, a Project Lead would be the original author of the Project charter. Once a Project has been approved and the Project Lead has been officially appointed by the PMC, the Project Lead must produce: a development plan for the release cycle, where the development plan must be approved by a majority of Committers of the Project. The plan must be submitted to the PMC for review. The PMC may provide feedback and advice on the plan but approval rests with the Project Committers.

Component Lead

When a component is deemed necessary by the Project Committers for a particular project, the Component Lead must produce: a development plan for the release cycle, where the development plan must be approved by a majority of Committers of the Component. The plan must be submitted to the Project Committers and the PMC for review. Both the Project Committers and the PMC may provide feedback and advice on the plan but approval rests with the Component Committers.

Project Infrastructure

The PMC works with the OSDU OMC to ensure the required infrastructure resources are provided for all PMC Projects. The Project infrastructure will include, at minimum:

  • Bug Database - Bugzilla database for tracking bugs and feature requests.
  • Source Repository - One or more repositories containing all the software for the Projects.
  • Website - A website will contain information about the Project, including documentation, reports and papers, courseware, downloads of releases, and this Charter.
  • [TO-DO: We need to link to the OSDU Marketing Site.]
  • General Mailing List - Mailing list for discussions pertaining to the Project or that cross Projects. This mailing list is open to the public.
  • Project Mailing Lists - Mailing list for technical discussions related to the Project. This mailing list is open to the public.
  • Component Mailing Lists - Mailing list for technical discussions related to the component. This mailing list is open to the public.
  • Newsgroups - Newsgroups where users, developers, and committers can interact regarding general questions and issues about the project. The newsgroup is open to the public.

Version History:

0.1 – Initial Draft – PMC team w/inputs from Stephen Whitley/OMC 0.2 – Feedback from Phillip Jong 0.3 – Added feedback from Johan Krebbers