-
Notifications
You must be signed in to change notification settings - Fork 26
Home
This document outlines the structure of the HEXRD community, its decision-makers, and workflows surrounding new features, bug-fixes, and release schedules.
Our Slack server is the primary location for real-time discussion of questions and comments about the library.
Broader, asynchronous conversation is hosted in our GitHub Discussions page. We treat this as a "Stack Overflow"-like forum to seek help with specific implementation questions.
The HEXRD community is directed by its Steering Committee, a body of scientists and core developers who decide which features will be committed to and when they will be officially released.
This committee is composed of...
Background
Background
Background
Features requested to be added to HEXRD must be submitted to the steering committee for review, and follow the guidelines for submission as follow below. Proposals are tracked in our GitHub Issues page, and if approved, will be assigned an estimated release version by the committee.
A Feature Proposal must follow the format to the best of the author's ability, providing reasonable context for the request. The proposal should provide concise specification for the feature, and appropriate rationale. It is strongly advised to limit the scope of the Proposal to a single feature, keeping it narrowly focused. If a Proposal is too broad, the Steering Committee may request that it be split into multiple, independent Proposals.
The guidelines for Feature Proposals are based on the Python Enhancement Proposal (PEP) guidelines. It is advised to follow the PEP guidelines described in PEP 1 to give the Proposal the best chance of being accepted.
The author and co-signatories of the Feature Proposal are responsible for building consensus within the HEXRD community, and documenting and responding to dissenting opinion.
A majority of the Steering Committee must vote to approve a Feature Request before it is accepted into the library.
# [Proposal Title]
## Description
[Brief 1-2 sentence summary of the feature being proposed.]
[One-paragraph abstract of the rationale for the Feature Proposal, and the implications it has on
the library as a whole.]
## Specification
[Detailed description of the feature, including any code snippets or examples that may be helpful to
the reader.]
## Rationale
[Explanation of why this feature is necessary, and how it will benefit the HEXRD community. It
should also describe alternative solutions that were considered, and why they were rejected.]
## Compatibility
[Description of how this feature will affect existing code, and whether it will be implemented in a
way that is backwards-compatible with previous versions of HEXRD. If the feature will include
changes which break existing code, such changes should be enumerated here. If the feature will
strictly not affect existing usability, this should be stated explicitly.]
## How to Teach This
[Description of how this feature will be taught to new users, and how it will be documented in the
HEXRD documentation.]
## Rejected Ideas
[Description of any ideas that were considered, and why they were rejected. This section should be a
living document, and should be updated as new ideas are considered.]
## Open Issues
[Description of any open issues that the author is aware of, and how they will be addressed in
future versions of the library. This section should be a living document, and should be updated as
new issues are discovered.]Contributions to the Hexrd library are welcome from any who want to offer their time. As the library is a collaboration across many groups and individuals, it is important to keep consistency in style, documentation, and testing standards.
Instructions for getting set up with the Hexrd library's development environment can be found on the main README.md file.
As Hexrd is a library of scientific software, the focus of code changes must be the utility that end-user scientists gain. The preferred path for contributing is to assume the work of an already-listed GitHub issue marked as ready for work, complete it as described, and provide a pull request for review. If the changes do not impact end-users in either software behavior or API use, it is assumed that the changes are for software maintenance, and requires the approval of the official development maintainers. If development work submitted in a PR has any impact on the behavior of one of the 4 workflows (EDD, HEDM, Laue, and Powder), it must be approved by a scientist assigned as an approver for such changes.
The package is composed of 4 workflow types, each maintained by a subcommittee of scientists who specialize in the workflow. Changes made to any of the main 4 Hexrd workflows must be requested by and approved by these groups. The committees and their organizers are listed here:
-
edd, organized by Kelly Nygren -
hedm, organized by Sven Gustafson -
laue, organized by Saransh Singh -
powder, organized by Christopher Budrow
Hexrd uses the PEP 8 style guide. To make things easy for developers, the black library can be used to force code to adhere to the style guide. Pull requests which do not conform to PEP 8 style will be automatically labeled as such in the comments of the PR, and justification must be provided by the requestor for approval.
The Hexrd library is relied on by scientists to do mission-critical research. To ensure the