Sally = purple
...
- Write access to the codebase (admin access??)Nomination privileges of new committers
- Privileges for nominating and voting on new committers
- Release management privileges
- Binding votes on procedural, code modification, and release issues (do we want this??)
- Access to the private committers mailing list (do we want guidelines re. what to use this for - i.e. is it just for voting in new members??)
Responsibilities
Committers share the following responsibilities:
- Monitor and respond to project mailing lists
- Attend project and technical
Responsibilities
Committers share the following responsibilities:
- Monitor and respond to project mailing lists
- Attend committer's group meetings
- Monitor and vet bug-tracker issuespull request and bug fixes on ASpace JIRA
- Review and commit code contributions
- Ensure code contributions are properly licensedGuide and mentor new committers
- Welcome new contributors , ask people who are contributing without a CLA to sign a CLA, and point them to CONTRIBUTING.md if needed.and help people with the process of contributing
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 a monthly meeting of the developers of ArchivesSpace, who discuss modifications and innovations in the code, and review new and open tickets. If you are interested in being added to the committers list, please contact us at xxxxx@xxxx with your name and Skype handle.
Process for Adding a New Committer Process
...
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.
...
Maintained by: Community Committers.
ACTION - Max to polish Labs text
- Link to same code guidelines but it's not a barrier - requiring some kind of identification - don't add stuff created by others without their permission
- Resources for best practices re. Github
- 2 ways code can get into labs
- fork projects into org
- adding people in
- group within larger Community Committers group that could provide group within larger Community Committers group that could provide some kind of oversight / determination re. what's deprecated - Patrick & Max happy to help with this (not sure if it's intergrations sub-team long term)
...
A good example to follow here is the IIIF Awesome repository. It contains only a README with links to IIIF examples and resources, and contributing guidelines. So instead of having a whole GitHub organization, this would be a repo (in the main archivesspace org?).
Group liked the IIIF Awesome repository and what Max has developed as a model.
- How do we handle 'internal' program staff contributions e.g. container checker?
- Not really helping the making 'it easier to share' / fork projects - does help with discovery
- Labs repo still good idea
- Approval may be the distinguishing factor? Wiki page v. GitHub
- IIIF-awesome copyright statement - applies only to wiki page - let's leave it off and not worry about it
- contributions to labs will require some kind of license - if there's a repository for people to add scripts, maybe there could be a copyright statement
DECISIONS:
- Hybrid approach - Some contribution of projects into Labs + IIIF-awesome type page
- updating page - anyone with commit privileges can be on the list to review pull requests on that page
- anyone can be added to org
- Cool ArchivesSpace projects
- those wanting to contribute scripts could just add to list - email contact if someone's totally lost
ACTIONS
- Esmé Cowles (Unlicensed) - Text describing what the organization is for - e.g. on text box at top - couple of sentences
___________________________________________________________________________________________________________________________________________________
...