Updated: May 17, 2019

This document describes the general policies and procedures that
are followed by the libfabric development community.  It is best
viewed as a guideline, and is not a formal or legal document.

Code contributions
------------------
Any developers wishing to contribute to libfabric may do so,
provided that they adhere to the CONTRIBUTORS agreement in the root
of the source tree.  There are no separate membership requirements
or documents that must be signed prior to submitting code.  Developers
need the rights to submit the code being introduced, and the code
must meet the license requirements of the project.

Git Repository Admin
--------------------
The number of people with administrative access to the github repo
will be limited.  Traditionally, this has been around three developers who
are active in the project, and are from different companies.  Admins
will typically have the same limitations as those with write access to
the repo, such as no forced updates.

Git Write Access
----------------
Because of the scope of the project, there may be several people (more
than 10) with write access.  Most writers are maintainers for a
specific provider in the project.  As a general rule, writers should only
commit changes to the subdirectory that corresponds with the provider
that they are maintaining.  Changes made to other providers or the
libfabric core must be approved prior by the relevant owners prior to
being merged.

Core Changes
------------
Updates to the libfabric core should be reviewed by at least one other
developer.  Changes to the API should be brought to the attention of
the OFIWG mailing list, with significant changes discussed prior to
being implemented.

Patch Submission
----------------
Patches should be submitted directly to github as part of a pull request.
For patches that touch the external API or introduce or modify core
functionality significantly, an email should be sent to the ofiwg mail
list with a link to the pull request.

Pull Requests
-------------
A number of continuous integration tests run against all pull requests.
Some CI testing involves access to special hardware, so is hosted
directly by various vendors.  Pull requests should not be merged until
after all CI completes.  In some cases, CI may fail, either because of
known issues, CI test node problems, or as a result of race conditions.
For CI failures that are unrelated to the pull request, the failures
may be ignored, and the pull request merged.  It is the responsibility
of the person committing the request to the repo to confirm that any
CI failures are unrelated to the changes in the pull request.

Releases
--------
A wiki page maintained on github with the repo provides a full checklist
of the release process.