-
Notifications
You must be signed in to change notification settings - Fork 25
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.]