Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Sally = purple

...

  • Monitor and respond to project mailing lists
  • Attend committer's group meetings
  • Monitor and vet pull request and bug fixes on ASpace 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

Committers are encouraged to speak with their organizations to clarify how contributions to the ArchivesSpace community fits into their role and what amount of time can be dedicated to contributing to the ArchivesSpace community.

...

ArchivesSpace Committers Calls are monthly meetings of the developers of ArchivesSpace, who discuss modifications and innovations in the code, and review new and open tickets. Calls are open to interested

...

This section describes the process for handling the voting of a new committer. Voting is handled by emailing the Committer List.

Summary: 

    1. Call Any existing committer can call a vote (insert link to template here - similar to templates/committerVote.txt)  – sounds good
    2. Close a vote (insert link to template here - similar to templates/closeCommitterVote.txt)
    3. Invite If the vote passes, the new committer is invited to join (insert link to template here - similar to templates/committerInvite.txt)

...

    1. Add to Committer team of GitHub archivesspace organization
    2. Add to Committer team of GitHub archivesspace-labs organization
    3. Add to archivesspace-committers google-group, group used nearly exclusively for this voting process
    4. Add to committers wiki page: ArchivesSpace Committers
    5. Announce the new committer committer (insert link to template here - similar to template/committerAnnounce.txt) - Users group & Google Group


Guidelines for assessing new candidates for committership

...

  • Ability to work cooperatively with peers - How do we evaluate? By the interactions they have through mail. By how they respond to criticism. By how they participate in decision-making process.
  • Ability to be a mentor - How do we evaluate? By the interactions they have through mail. By how clear they are and how willing they are to point at appropriate background materials (or even create them).
  • Community - How do we evaluate? By the interactions they have through mail. Do they help to answer questions raised on the mailing list; do they show a helpful attitude and respect for other's ideas.
  • Commitment - How do we evaluate? By time, by sticking through tough issues, by helping on not-so-fun tasks as well. 
    • Do committers have an ongoing committment of time? ← may not want to impose barriers but if they're not active they're not contributing
  • Personal skill/ability - How do we evaluate? A solid general understanding of the project. Quality of discussion in mail. Patches (where applicable) easy to apply with only a cursory review. All contributors should have submitted at least one pull request to the project.

...

  1. Make sure that you have completed an Individual Contributor License Agreement, or that your institution has completed an Corporate Contributor License Agreement.

  2. Find or create a bug report or feature request ticket in JIRA GitHub (to make sure you’re not duplicating work and document the intent of your contribution). It helps to explain both the existing behavior and the desired behavior that your change will implement.

  3. Set up a GitHub account if you have not done so before.

  4. Fork the ArchivesSpace repository on GitHub.

  5. Create a feature branch.

  6. Make changes in your fork. We advise contributors to follow these guidelines to expedite the contribution review process.

    1. Follow established style guidelines

      1. Rails: https://github.com/bbatsov/rails-style-guide

      2. JRuby: https://github.com/jruby/jruby/wiki/JRubyStyleGuide

      3. RSpec: http://betterspecs.org/

    2. Include unit tests sufficient to cover the feature(s) you add or bug(s) you fix, and make sure the test suite passes. (Can we rely upon Travis or a Jenkins instance for this, or should we suggest that contributors run tests locally?)

    3. If you’re adding a feature or otherwise changing documented behavior, modify the documentation to reflect your changes.

  7. Once your work is done, squash the commits in your branch — see One Commit per Pull Request for some guidelines — and rebase it on the latest in the upstream master branch. We appreciate succinct but explanatory commit messages.

  8. Push your updated branch to your fork.

  9. Create a Pull Request on GitHub.

  10. Respond to feedback as the community reviews your contribution.

...