Sally = purple
...
The following is an alphabetized list of the current ArchivesSpace committers:
| Name | Organization |
|---|---|
A full list of all known community and emeritus contributors can be found here.
...
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?)
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.
...
Once the code is made available, the Committers Group will take time to review the work and provide feedback/comments. Code must be reviewed by at least one other committer from another organization before it can be merged.
Usually, one (or more) committers who are interested in this work will contact you and discuss any feedback we have, and whether or not there would need to be some general changes before we could accept it. Some patches/features are readily accepted (because they are stable and look good), others may require more work (if there are concerns or issues that Committers notice).
The timeframe of a code review will vary, based on how much time the Committers have. Smaller changes may be reviewed within days, while larger changes/features may take many weeks to do a full review. All Committers are volunteers and only have a small amount of time to provide to the project in a given week. We will make every effort to get back to you with feedback within a few weeks. But, if you haven't heard anything, feel free to ask! (is this the right process for us?)
...
We'll also want to define 'rights and responsibilities' of core committers that specify good practice such as not merging your own code, etc. <--- Fedora has a good 'rights and responsibilities' doc that we can probably use as a model. (this one: https://fedoraproject.org/wiki/Package_maintainer_responsibilities??)
3. Reworking Code (if necessary) & Next Steps
...
Once your code is accepted, it will be released in the next version of DSpace software! It is time to celebrate, as your name will be added to the prestigious list of DSpace Contributors!
----------------------
We'll also want to define 'rights and responsibilities' of core committers that specify good practice such as not merging your own code, etc. <--- Fedora has a good 'rights and responsibilities' doc that we can probably use as a model. (this one: https://fedoraproject.org/wiki/Package_maintainer_responsibilities??)General discussion notes:
Oversight for the core committers comes from the Program Team developer(s) and other established core committers ... Islandora - has text about this; but doesn't start from scratch
...