Skip to content

Latest commit

 

History

History
171 lines (111 loc) · 9.35 KB

GOVERNANCE.md

File metadata and controls

171 lines (111 loc) · 9.35 KB

OpenLineage Governance

The OpenLineage project provides content (standards, data, code and documentation) that is intended for wide consumption across many types of organizations - from those that rely on data in their operation - to organizations that have products or technology designed to help manage data and its related processing.

A project of this scope requires input from a wide range of subject matter experts with different backgrounds and allegiances. As such we need a set of principles, roles and operating practices to ensure the results of our contributions are useful, have high quality and are widely consumable.

General principles

The principles set the tone of the operation of OpenLineage:

  • The activities of the project ensure open collaboration. Through this open collaboration we aim to build a community of people who are interested in the success of the project.
  • The scope of the content is determined by the individuals who are actively contributing.
  • The resulting content is licensed under the Apache 2.0 license.
  • An individual's privileges and position is awarded through their contribution and engagement.

These principles should be respected as the procedures used to manage the OpenLineage project are evolved and matured.

OpenLineage community members

Anyone can become a member of the OpenLineage community by signing up to the the OpenLineage mailing list, joining the slack community, attending the project online meetings or contributing content to one of more of the GitHub repositories.

The Contribution Guide describes how to connect to these channels.

All participants in the OpenLineage community are bound by the project's Code of Conduct.

As a member you are able to attend our meetings, just to listen, or to play an active part in the discussion. The online meetings are recorded to allow community members to catch up if they are not able to attend the live meeting. When you attend the community meetings specifically, your name will be recorded in the meeting minutes along with any remarks or suggestions you make. The agenda and minutes of our community meetings are publicly available on the wiki.

A member may make contributions to the OpenLineage content by submitting a GitHub pull request on the appropriate Git repository. This will be reviewed and processed by the OpenLineage committers.

Each contribution is signed by the contributor to confirm they agree to our Developer Certificate of Origin (DCO).

Community members can progress to be OpenLineage Contributors and then OpenLineage Committers.

OpenLineage contributors

OpenLineage contributors are members who have actively taken additional steps to promote and foster the success of OpenLineage and its acceptance/adoption across the IT community. The activities that contributors engage in might include:

  • Provide best practices for information governance, lineage, metadata management and other related disciplines during active discussions and/or development of material
  • Actively participate in meetings and discussions
  • Promote the goals of OpenLineage and the benefits of open metadata to the IT community (deliver presentations, informal talks, assist at trade shows, independent blogs, etc.)
  • Assist in the recruitment of new members
  • Contribute where appropriate to documentation and code reviews, specification development, demonstration assets and other artifacts that help move OpenLineage forward

How to become a contributor

Being recognized as an OpenLineage contributor is done by nomination of an OpenLineage committers with a majority vote of OpenLineage committers to confirm.

OpenLineage's contributors are recognized in the contributors list.

OpenLineage project committers

Committers are members of the OpenLineage community that have permission to change the OpenLineage content. This may be content that they have created themselves, or has been provided by another member. Committers also have responsibility for helping other project members with their contributions. This includes:

  • Monitoring email aliases.
  • Monitoring Slack (delayed response is perfectly acceptable).
  • Triage GitHub issues and perform pull request reviews for other maintainers and the community.
  • Make sure that ongoing git pull requests are moving forward at the right pace or closing them.

How to become a committer

New committers are voted onto the committers list by the existing committers - see committer list.

Upon a new nomination, the committers vote; if there are at least 3 votes in support of the nominee and no vetoes in a period of three days, the nominee becomes a committer. If there are vetoes, a majority of all committers is required to approve the nominee. Once accepted, the nominee is added to the committers list and given write access to the git repositories.

Once confirmed, nominees can publicly refer to themselves as OpenLineage committers.

When does a committer lose maintainer status?

If a committer is no longer interested or cannot perform the committer duties listed above, they should volunteer to be moved to emeritus status. In extreme cases this can also occur by a vote of the committers per the voting process below. Emeritus committers can rejoin the committer list through a vote of the existing committers.

OpenLineage leadership

The leadership of OpenLineage is granted through a vote of the OpenLineage committers. OpenLineage is currently led by Julien Le Dem.

OpenLineage project meetings

Some meetings are face-to-face, but most are conference calls.

Attendance at meetings is open to all. Conference calls can be joined without an explicit invitation. However, due to physical security requirements at some of the venues we use, it is necessary to ensure you are added to the invitee list of any face-to-face meetings that you wish to attend and complete the necessary formalities for the venue.

For example, the face-to-face meeting may be at a conference that requires you to register for the conference to attend. Or a meeting may be at an organization's offices that are required to maintain a list of everyone on site.

OpenLineage on Slack

OpenLineage uses the a Slack community to provide an ongoing dialogue between members. This creates a recorded discussion of design decisions and discussions that complement the project meetings.

Follow the link above and register with the slack service using your email address. Once signed in you can see all of the active slack channels.

Additional channels are added from time to time as new workgroups and discussion topics are established.

OpenLineage email

OpenLineage uses the discussion list for more general discussion.

OpenLineage content management tools

The OpenLineage content is managed in GitHub under https://github.com/OpenLineage/OpenLineage. It may be developed using patches, branches from main, or forks/git pull requests. Each change should have a GitHub issue explaining why the change is being made. For more information about contributing, read the contributors guide.

When new content proposed to the project, the person contributing is required to sign the contribution to confirm it conforms to the Developer Certificate of Origin (DCO).

OpenLineage project releases

The OpenLineage team aim to create regular official release of OpenLineage.

In between official releases, the latest build is also available to developers in GitHub.

Release cadence

A release will be initiated on the first business day of each month except when this is a Friday, in which case the release will commence on the next business day.

Release process

Anyone may request a new release of the project in the #general channel.

After one is proposed, committers have 48 hours to give a +1 or -1.

A total of three +1s, taking into account -1s and excluding votes by the proposer, authorize the release.

Alternatively, if after 2 days the release has received at least one +1 and no -1s, the release is also authorized.

If the proposed release receives no +1s in two days, it is not authorized and the proposer must make a new request to reset the clock.

Once a release is authorized, it will be initiated within two business days. Releases will not be made on a Friday unless doing so will address an important defect, an issue with project infrastructure, or a security vulnerability.

If a release build fails or is delayed for up to three business days after initiation for a purely technical reason, the next point release is automatically authorized after the build and release process has been fixed.

Conflict resolution and voting

In general, we prefer that technical issues and committer membership are amicably worked out between the persons involved. If a dispute cannot be decided independently, the committers can be called in to decide an issue. If the committers themselves cannot decide an issue, the issue will be resolved by voting. The voting process is a simple majority in which each committer receives one vote.


SPDX-License-Identifier: Apache-2.0
Copyright 2018-2023 contributors to the OpenLineage project