Page Comparison

Sally = purple

Max = orange

...

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

...

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.

...

• The code is stable and has no stability or security concerns
• The code is properly using existing APIs, etc.
• The code is not too specific to one institution's local policies or workflows. (I.e. we will review the code to ensure it looks to be generally useful to most institutions, or configurable enough such that others can change it to match their own local policies/workflows)
• Any third-party tools/libraries used by your code have compatible open source licenses. See Licensing of Contributions

There is some work on these kinds of contributing guidelines going on in the Hydra community right now, here are some updated docs that might have some good stuff to include here:

• https://github.com/escowles/technical-onboarding/blob/master/code.md
• https://github.com/escowles/technical-onboarding/blob/master/review.md

---------------

Code approval process - how to get your code into ArchivesSpace! (adapted from https://wiki.duraspace.org/display/DSPACE/Code+Contribution+Guidelines)

...