Sally = purple
...
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
...
- Any existing committer can call a vote (insert link to template here - similar to templates/committerVote.txt) – sounds good
- Close a vote (insert link to template here - similar to templates/closeCommitterVote.txt) <---- need half of people voting +1 and no -1 ones
- If the vote passes with no vetoes, the new committer is invited to join (insert link to template here - similar to templates/committerInvite.txt)
...
Make sure that you have completed an Individual Contributor License Agreement, or that your institution has completed an Corporate Contributor License Agreement.
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.
Set up a GitHub account if you have not done so before.
Fork the ArchivesSpace repository on GitHub.
Create a feature branch.
Make changes in your fork. We advise contributors to follow these guidelines to expedite the contribution review process.
Follow established style guidelines
RSpec: http://betterspecs.org/
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?) → would be good to run travis locally
If you’re adding a feature or otherwise changing documented behavior, modify the documentation to reflect your changes.
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.
Push your updated branch to your fork.
Create a Pull Request on GitHub.
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
...
- 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
...
- for non-committers (adapted from https://wiki.duraspace
...
.org/display/DSPACE/Code+Contribution+Guidelines)
Encourage smaller contributions and smaller pull requests in sequence when possible.
Before you start, make sure you're talking to people – use email or Github issues?
- if you have a bigger, open-ended question then list
- more focused / smaller question, then Github issue
may need to use multiple channels anyways
ACTION - merge this kind of doc w/ the Core Contribution Guidlines
0. Share Early, Share Often!
...
- Please be sure to share your plans with the ArchivesSpace community on the (ArchivesSpace users?) list (or via one of the monthly Developer Meetings) before embarking on any sizable development effort. This will ensure you achieve your goals in a way that is consistent with the ArchivesSpace architecture and plans of the rest of the community. It will minimize the chances of a scenario where you have invested a large amount of time and effort into a body of code that does not fit in with the ArchivesSpace architecture or the consensus of the community. (Note - do we need some kind of distinction between large & and small contributions? Larger contributions should be evaluated by the User Community - perhaps via a process similar to this: http://islandora.ca/developers/lsap)
- Develop incrementally; try and implement and contribute a basic form of your feature as soon as possible, rather than aiming to implement a complete and 'polished' solution. This will help ensure you're on the right track with regards to the rest of the ArchivesSpace community and platform. The sooner your code is part of the core code base, the less time you will have to spend 'chasing' the main code base, i.e. keeping your changes up-to-date with that core code base.
- Obtain the DSpace ArchivesSpace code using GitHub (see also Development with Git). This will make code management much easier. It's very simple to do; see Developer Guidelines and Tools.
- Read Code Contribution Guidelines (this page) to ensure you are following ArchivesSpace conventions. This will ensure your code is more likely to be immediately accepted as part of out-of-the-box ArchivesSpace.
- Ensure that any third-party tools/libraries that you plan to utilize are released under compatible open source licenses. See the Licensing of Contributions section below.
- For Larger Initiatives/Codebases: If you are building out a much larger project, we highly recommend notifying the community of the work early on via an email to dspace-devel@googlegroups.com. to both Google Group and Member List. This can help find collaborators or get early feedback. We also recommend you develop your project in GitHub, as it provides easier ways to review/collaborate with other developers.
...
Actions from November 7th, 2016 call:
- Esmé Cowles (Unlicensed) to add links Hydra to code contribution guidelines to
- Update Contribution to ArchivesSpace page to reflect current
- Create separate 'clean' doc?
...