github/CommonCoreOntologies
1
1
Fork 0
mirror of https://github.com/CommonCoreOntology/CommonCoreOntologies.git synced 2026-01-12 08:08:23 -05:00
Code Issues Packages Projects Releases Wiki Activity
Files
develop
CommonCoreOntologies/documentation/contributing
History

README.md

Short Instructions for Contributing to CCO

All contributions to CCO are expected to follow Github’s Code of Conduct and the CCO Contributing Guidelines and Code of Conduct.

For detailed instructions on contributing to CCO, see the contributing documentation section.

Forums

Before contributing to CCO, please ensure comments are posted to the appropriate forum:

Issue Tracker

• Posts to the issue tracker shall provide specific, targeted suggestions, or shall be anticipated to arrive at such guidance after brief discussion. The broader goal is to ensure there are no unresolved issues at the time of a release. Well-described issues and concrete tasks help CCO developers execute requested changes quickly and effectively.

• For these reasons, when making a request or reporting a problem or bug to the issue tracker, always attempt to provide a corresponding solution that would allow others to, if they agree, immediately make updates based on your guidance. That said, it is ok to ask others for solutions, so long as it is foreseeable that subsequent posts will easily hit upon an acceptable solution.

• Posts that fail to follow this guidance will be removed or converted to a discussion.

Discussion Forum

• Open-ended comments or questions should be posted to the discussion board. It can also be used to evaluate larger solutions or to build consensus for a suggested major revision.

• Once consensus is reached on a change, the suggestion should be placed on the issue tracker for execution.

Pull Requests

Opening Pull Requests

  1. In general, pull requests should only be opened when a specific change on the issue tracker has received approval from a member of the developer group.
  2. When applicable, the name of the branch associated with the PR and its commit message should contain the issue number the change resolves.
  3. In general, pull requests should reflect small, targeted updates. This simplifies reviewing such pull requests and decreases the risk that mistakes will be inadvertently committed. If multiple sets of changes are being made in the PR, to expedite the review process, group similar changes together in thematically grouped commits.
  4. In rare cases, making a larger number of changes on a single PR is warranted. Before opening such a PR, ensure there is a clear and concise list describing all changes made in the PR. This list should be shared on the issue tracker and approved by a member of the developer group before creating the PR.
  5. Assign your PR to a reviewer within the developer’s group.
  6. Please ensure one or more of the following people are also tagged: John Beverley, Mark Jensen, Alexander Cox, and Neil Otte.

Reviewing Pull Requests

  1. Reviews are specific to the changes proposed under the PR. A PR review is not the place to open tangential issues. Those should be posted in the discussion forum or issue tracker as appropriate.

  2. If improvements are required, clarify what needs to be done before the PR can be merged and what can be implemented later. Open a corresponding issue or discussion thread to address future improvements.

  3. Adopt a constructive mindset and use positive language when leaving reviews. For example, write “I suggest” or “You could improve X by doing Y.” Avoid phrases such as “Do this” or “This is just wrong, why don’t you do Z?”.

    See also: https://medium.com/prodigy-engineering/reviewing-pull-requests-delightfully-f0b9faf5cafd

Reference in New Issue View Git Blame Copy Permalink