Core Committers Group
...
ArchivesSpace is an opensource program and is released under the Educational Community License, version 2.0 (http://opensource.org/licenses/ecl2.php). As such, t| Anchor |
|---|
_GoBack | _GoBack | he the software and associated documentation is developed collectively by a community of contributors and committers. All interested community members are encouraged to contribute to ArchivesSpace. Contributors who demonstrate sustained engagement with ArchivesSpace through quality participation in meetings, mailing lists, documentation and code updates can be nominated by existing core committers to become a core committer. It should be emphasized that committers need not be limited to software developers. Community members with skills in documentation and testing, for example, can also be core committers.
Core committers share the following rights:
- Write access to the codebase in GitHub
- Privileges for nominating and voting on new core committers
Core committers share the following responsibilities:
...
Core Committers Group calls
ArchivesSpace core committers calls are monthly meetings of the core committers of ArchivesSpace, who discuss modifications and innovations in the code, and review new and open tickets. Calls are open to all interested community members. Information about these open calls can be found here: https://archivesspace.atlassian.net/wiki/spaces/ADC/pages/312836097/Call+in+information.
Process for Adding a New Core Committer
This section describes the process for handling the voting for a new core committer. Voting is handled by email.
- Any existing core committer can call a vote.
- Close a vote (requires at least half of core committers voting +1 and no -1).
- If the vote passes with no vetoes, the new core committer is invited to join.
If the new committer accepts, then do the following:
- Add to Core committer team of GitHub archivesspace organization
- Add to Core committer team of GitHub archivesspace-labs organization
- Add to archivesspace-core-committers google-group, group used exclusively for this voting process
- Add to core committers wiki page: ArchivesSpace Core Committers
- Announce the new core committer to the ArchivesSpace Users Group.
Guidelines for assessing new candidates for core committership
When a contributor is nominated to become a core committer, the following guidelines should be used by existing core committers to evaluate the nominee's suitability:
...
When Reviewing a Pull Request
Pull requests are evaluated in many different ways; fortunately, we have tools to help us with code review so that human review can focus on overall code quality and maintainability. For instance, we use TravisCI, to ensure the current automated test suite is passing.
When reviewing a pull request, please take the time to review the changes and get a sense of what is being changed.
The key things to focus on are:
- Are the PR description and commit messages clear?
- Do the functional code changes match the PR description?
- Does the PR contain tests for new features or bugfixes?
- Not all PRs require tests, such as wording changes or simple refactoring.
- Does the commit contain more than it should? Are two separate concerns being addressed in one commit?
As a reviewer, it's also your responsibility to make sure:
- the Travis tests completed successfully
- all new or changed methods, modules, and classes have comments where needed
Merging Pull Requests
When merging pull requests:
- Give discussion time to settle down. When there is a contentious discussion, please allow 24 hours before merging to make sure everyone's had a chance to respond.
- It is considered "poor form" to merge your own request, and you should be cautious when merging pull requests from other developers at your own institution.
- If you are uncertain, bring other core committers into the conversation by creating a comment that includes their @username.
- If you like the pull request, but want others to chime in, create a +1 comment and tag another core committer.
- If you merge the pull request, you should delete the corresponding branch if the branch is in one of the ArchivesSpace GitHub repositories
This document is based upon the original ArchivesSpace re-org and committer groups proposal, the Subversion Community Guide, and documentation from several open source projects – Islandora, DSpace, and Hydra.