Page Comparison

Sally = purple

Max = orange

...

https://docs.google.com/spreadsheets/d/1S5C217M3JUZfHSlLarQjAUqCofJ9jMi_C2VIGvyT8KA/edit?usp=sharing

Github structure: 

Propose creating / maintaining these organizations: 

Most documentation should be in confluence wiki & links in Github readmes.

https://github.com/Islandora/islandora/wiki/Islandora-Committers

___________________________________________________________________________________________________________________________________________________

https://github.com/archivesspace/

Purpose: contains the core ArchivesSpace repositories, including the main project and migration
tools. All code here is officially supported and maintained by at least the ArchivesSpace
Program Team.

Committer Policy: 

Maintained by: Program Team, Core Committers.

1. Make sure that you have completed an Individual Contributor License Agreement, or that your institution has completed an Corporate Contributor License Agreement. (NOTE: this is not strictly necessary, though it is recommended, for contributions to ArchivesSpace Labs code repositories.)

2. Find or create a bug report or feature request ticket in Pivotal Tracker or 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.

Core Committers Group: (note - do we need to call out program staff as a separate group??)

ArchivesSpace is open source and released under ECL, v 2.0. The software and associated documentation is developed collectively by a community of contributors and committers. All interested community members are encouraged to contribute to the project. Contributors who demonstrate sustained engagement with the project through quality participation in meetings, mailing lists, documentation and code updates can be nominated by existing committers to also become a committers. It should be emphasized that committers need not be limited to software developers. Community members with skills in documentation and testing, for example, can also be committers.

Committers share the following rights:

• Write access to the codebase (admin access??)
• Nomination privileges of new committers
• Release management privileges
• Binding votes on procedural, code modification, and release issues
• Access to the private committers mailing list

Committers share the following responsibilities:

• Monitor and respond to project mailing lists
• Attend project and technical meetings
• Monitor and vet bug-tracker issues
• Review and commit code contributions
• Ensure code contributions are properly licensed
• Guide 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.

Process / criteria for adding new members: 

A private mailing list for existing code contributors; any existing code contributor can email the list to propose a new member who has submitted at least one PR. The group then votes on the new member - they nearly always get confirmed. The group could see ArchivesSpace adopting a similar mechanism.

• We'll need to define a process for code review 
• 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. 

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 

• For starters - get a starter group 5 -6 people
• Page with these are the committers
• Github - links to email addresses, etc.
• Rights 

What we need: 

•  Get agreement from 4 -5 people as a starter group
•  Describe core committer nominations process 
•  Define rights & responsibilities
  •  include guideline that you get your employer's blessing?
•  In Github page describe who people are w/ links to who core committers are & what their communication process is - e.g. development meetings (e.g. biweekly or monthly) - Hydra & Fedora have weekly - for ?s, work underway - e.g. release; i want to make this big change, should I wait or is that cool?; also a good place to just get updates on technical progress of project

Review:

•  ACTION - Code in this organization must adhere to x guidelines (test coverage and/or documentation) - cleaning up text - Sally - with group to review afterwards; 
  • Codifying existing practices
  • Test coverage; passing test

•  ACTION - Review both https://github.com/Islandora/islandora/wiki/Islandora-Committers

...

•  and Contributing to ArchivesSpace

...

•  to see if we'd like to add to Contributing to ArchivesSpace page 

___________________________________________________________________________________________________________________________________________________

https://github.com/archivesspace­plugins/ 

Purpose: contains plugins officially supported by at least the ArchivesSpace Program Team.
These plugins are tested and updated as necessary to be compatible with new releases.
Provides a focal point to discover plugins and contribute to their development. 

...

Maintained by: Program Team, Core Committers. (plugin committers?) <--- believe we decided on 8/24 not to have a separate plugin committers group

___________________________________________________________________________________________________________________________________________________

https://github.com/archivesspace­labs/
Purpose: contains proof of concepts, examples and experimental projects. There is no official
support from the Program Team for anything in labs. The projects are not guaranteed to be up
to date with the latest release and are used on a at­your­own­risk basis. Program Team and
other “official” committers can contribute to labs but that does not confer official support to any
project. Note - Labs branding should make it clear that none of the projects are officially supported. 

...

https://github.com/archivesspace­deprecated/
Purpose: contains repositories that should no longer be used with ArchivesSpace or that have
become generally obsolete.

Maintained by: Program Team, Core Committers.Committer groups:
Program Team: only employees of ArchivesSpace can be part of this group. Access to
everything (admin).
Core Committers: devs with experience of contributing to ArchivesSpace, trusted to review and
merge pull requests etc. Access to everything (admin).

Process / criteria for adding new members: 

A private mailing list for existing code contributors; any existing code contributor can email the list to propose a new member who has submitted at least one PR. The group then votes on the new member - they nearly always get confirmed. The group could see ArchivesSpace adopting a similar mechanism.

• We'll need to define a process for code review 
• 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. 

Oversight for the core committers comes from the Program Team developer(s) and other
established core committers ...
Plugin committers: not sure is needed? Group that can have access to all plugin repos.

• Islandora - has text about this; but doesn't start from scratch 
• For starters - get a starter group 5 -6 people
• Page with these are the committers
• Github - links to email addresses, etc.
• Rights 

What we need: 

...

•  include guideline that you get your employer's blessing?

...

...

Community Committers: Any developer wanting to contribute a project to labs or work within it.
Access to labs (write access).There are no minimum requirements for adding resources to labs. Adherence with y coding guidelines and inclusion of some documentation is encouraged but not required. 

...

Oversight for the community committers comes from TAC (a new subgroup or the existing
comitters oversight group?). One member of the subgroup will be responsible for adding new
members (should be a committer or promoted to one?). Criteria for new members? Anyone who
requests access?
Committer policies:  
Test coverage and / or documentation requirements. Will differ per org?
Merge policy (i.e. don’t merge your own work ...)
Plugin submission process:
Need to define how to submit a plugin to become official ...

tried to incorporate notes in this section into description of areas and groups above 

Deprecation process:

To deprecate a repository it must first be announced to the mailing list for input. If there are no
objections then the the Program Team Manager should confirm the status.With approval the 

...

If there are regular tech team meetings it can be raised. Minor issues:
Labs branding and making it clear that none of the projects are officially supported.

incorporated this note in plugin section above

___________________________________________________________________________________________________________________________________________________

Actions from September 14th, 2016 call:

•  Sally Vermaaten (Unlicensed) to polish / borrow text to flesh out code guidelines (group to review afterwards)
  
•  Max Eckard to polish / borrow text re. Labs area 
  
•  All to discuss updated text and continue to flesh out other areas in next meeting - Sally Vermaaten (Unlicensed) to send out Doodle for next time
  

Next stepsOverall Plan: 

•  Complete committer group definitions and process for adding members; policies etc. 
•  When ready announce plan to mailing list.
•  Create the organizations.
•  Transfer repositories to assigned org per:
•  https://docs.google.com/spreadsheets/d/1S5C217M3JUZfHSlLarQjAUqCofJ9jMi_C2VIGvyT8KA
•  /edit
•  Announce to list.