Skip to content

Latest commit

 

History

History
233 lines (173 loc) · 11.9 KB

Egeria-Operations.md

File metadata and controls

233 lines (173 loc) · 11.9 KB

Egeria Operations

The Egeria 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 Egeria:

  • 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 Egeria project are evolved and matured.

What does it mean to be part of the Egeria community?

All participants in the Egeria community are bound by the ODPi's Code of Conduct. There are different roles in the Egeria project.

Egeria project members

Anyone can become a member of the Egeria community by signing up to the mailing list. As a member you are able to attend our meetings, just to listen, or to play an active part in the discussion.

When you attend, your name will be recorded in the meeting minutes along with any remarks or suggestions you make. The agenda and minutes of our meetings are publicly available on the Egeria wiki.

A member may make contributions to the Egeria content by submitting a Git change (Patch or a Git Pull Request) to the Egeria maintainers. See the Community Guide.

Egeria contributors

Egeria contributors are members who have actively taken additional steps to promote and foster the success of Egeria 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 ODPi Egeria 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 Egeria forward

How to become a contributor

Being recognized as an Egeria contributor is done by nomination of an Egeria maintainer with a majority vote of Egeria maintainers to confirm. Once confirmed, you will recieve a badge to add to your social profiles and/or website, and can refer to yourself as an Egeria contributor publically.

Egeria project maintainers

Maintainers are members of the Egeria community that have permission to change the Egeria content. This may be content that they have created themselves, or has been provided by another member. Maintainers 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.
  • In general continue to be willing to spend at least 25% of one's time working on the project (approximately 1.25 business days per week).

How to become a maintainer

New maintainers are voted onto the maintainers list by the existing maintainers - see maintainer list.

A person wishing to become a maintainer sends a note to the existing maintainers at [email protected], listing their Egeria contributions to date and requesting to be made a maintainer. The maintainers vote and if a majority agree then the requester is added to the maintainers list and given write access to our git repository.

Once confirmed, you will recieve a badge to add to your social profiles and/or website, and can refer to yourself as an Egeria maintainer publically.

When does a maintainer lose maintainer status

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

ODPi Egeria leadership

The leadership of ODPi Egeria is grated through a vote of the Egeria maintainers. ODPi Egeria is currently lead by Mandy Chessell.

Egeria project meetings

Some meetings are face-to-face, but most are conference calls. For example, there is a weekly call covering both the ODPi Egeria, and its sister project ODPi Data Governance, every Thursday. Follow this link to find out more.

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.

Irrespective of whether a meeting is face-to-face or a web conference, all meetings are advertised in the Egeria calendar, the agenda is published before the meeting in the Egeria wiki and the minutes are added once the meeting is complete.

Egeria on Slack

Egeria uses the ODPi's Slack community to provide an ongoing dialogue between members. This creates a recorded discussion of design decisions and discussions that complement the project meetings. This is the main slack channel for the Egeria project: https://odpi.slack.com/messages/CAZDMLTFF. Additional channels will be added as new workgroups and discussion topics are established.

Egeria email

Egeria uses the following distribution list to advertise events and news for the community.

Egeria content management tools

The Egeria content is managed in GitHub under https://github.com/odpi/egeria. It may be developed using patches, branches from master, or forks/git pull requests. Each change should have a GitHub issue explaining why the change is being made. The new or updated content should follow the Egeria developer guidelines.

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).

Egeria project releases

The Egeria team aim to create an official release of the open metadata and governance capability twice a year. This release will be available to include in products and other technology through Maven's Central Repository, or through a download from the ODPi site.

In between official releases, the latest build is also available to developers, through the Egeria site.

Release Process Overview

Releases are published to Bintray where they are GPG signed and distributed to Maven Central.

Creating a new release has the following stages:

  • Creating a branch off master for the release code.
  • Incrementing the release numbers in the pom files in master and committing through a pull request.
  • Within the branch removing "-SNAPSHOT" from all of the Egeria version numbers in the pom files and committing with a pull request.
  • Staging a release through Azure Pipelines
  • Verifying release criteria are met on the staged build
  • Promotion of the release from staging to release
  • Distribution of the release to Bintray, which is then replicated to Maven Central.
  • Documenting the release with a Git Release.

Release Process Steps for Maintainers

New releases can be created by Egeria maintainers that have the appropriate access on Azure Pipelines.

Creating a new release has the following stages following the release branch creation:

  1. Update the Azure Release Pipeline to use the release branch

    1. Click "Edit"
    2. Click _ODPI_Egeria_Commit under the "Artifacts" column
    3. Modify Default branch to be the new release branch
    4. Click Save to the right of the breadcrumb header
  2. Stage a release though Azure Pipelines

    1. Click Create release
    2. Select commit id from Version dropdown.
    3. Click Create

    Pulling from the staging repository can be done through Maven with the following settings:

    <repositories>
      <repository>
        <snapshots>
          <enabled>false</enabled>
        </snapshots>
        <id>central</id>
        <name>egeria-staging</name>
        <url>https://odpi.jfrog.io/odpi/egeria-staging</url>
      </repository>
    </repositories>
    <pluginRepositories>
      <pluginRepository>
        <snapshots>
          <enabled>false</enabled>
        </snapshots>
        <id>central</id>
        <name>egeria-staging</name>
        <url>https://odpi.jfrog.io/odpi/egeria-staging</url>
      </pluginRepository>
    </pluginRepositories>
    
  3. After the community verifies the staged artifacts meet the release criteria, the Promote to Release step will be approved (and the Abandon Release step canceled) If the artifacts do not meet the criteria, the Promote to Release step should be denied, and Abandon Release should be approved. The release process should then be started again at step #2 from a different commit once changes have been merged.

  4. After the release promotion is approved, the artifacts will be distributed to Bintray which will sign them and sync them to Maven Central.

Conflict resolution and voting

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


License: CC BY 4.0, Copyright Contributors to the ODPi Egeria project.