Core Committers Group

ArchivesSpace is an open­source program and is released under the Educational Community License, version 2.0 (http://opensource.org/licenses/ecl2.php). As such, 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:

• Monitor and respond to program mailing lists
• Attend core committers' group meetings
• Monitor and vet pull requests and bug fixes on ArchivesSpace JIRA
• Review and commit code contributions
• Ensure code contributions are properly licensed
• Welcome new contributors and help people with the process of contributing 
• Stay active in the community

Core committers are encouraged to speak with their organizations to clarify how contributions to the ArchivesSpace community fit into their role and what amount of time can be dedicated to contributing to the ArchivesSpace community.
A full list of the Core Committer's Group can be found here: https://archivesspace.atlassian.net/wiki/spaces/ADC/pages/102893918/Core+Committers+Group.

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.

1. Any existing core committer can call a vote.
2. Close a vote (requires at least half of core committers voting +1 and no -1).
3. If the vote passes with no vetoes, the new core committer is invited to join.

If the new committer accepts, then do the following:

1. Add to Core committer team of GitHub archivesspace organization
2. Add to Core committer team of GitHub archivesspace-labs organization
3. Add to archivesspace-core-committers google-group, group used exclusively for this voting process
4. Add to core committers wiki page: ArchivesSpace Core Committers
5. 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:

• Ability to work cooperatively with peers – Evaluated by the interactions they have through mailing lists, by how they respond to criticism and by how they participate in decision-making process.
• Ability to be a mentor – Evaluated by the interactions they have through mailing lists, by how clear they are when explaining a concept, and by how willing they are to point at appropriate background materials (or even create them).
• Community – Evaluated by the interactions they have through mailing lists. Do they help to answer questions raised on the mailing list? Do they show a helpful attitude and respect for others' ideas?
• Commitment – Evaluated by the amount of time contributed to the community, by sticking through tough issues, and by helping on not-so-fun tasks as well.
• Personal skill/ability – Evaluated by showing a solid general understanding of ArchivesSpace, by the quality of discussion participation on the mailing lists, and by the ease with which pull requests can be reviewed.

To be eligible, the nominated contributor must have submitted at least one pull request to ArchivesSpace.

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

Acknowledgements

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.