Sally = purple

Max = orange

Dave = Blue

Re-org:

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. 

Committer Policy: 

• Linking to same guideline but noting plugins can be difficult to test so that requirement could be lowered
• ACTION - Approval process to be considered 'official plugin' 
• fedora doesn't have a formal process - instead there must be 2 people willing to support - if one committer leaves have to find 2nd or it's deprecated; ASpace is different in that it's a program responsibilitity. 
  • could instead use principles of: generic applicability; plugin quality (against coding guidelines)
  • approvers - core committer group + program team members; to assess applicability - putting out message on list (community voting- how many people would use)

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. 

Committer Policy: 

• This area is open to any contributions and there are no minimum requirements for adding scripts, etc. 
• Adherence with y coding guidelines and inclusion of some documentation is encouraged but not required. 

(Core committers? Committers Oversight?) will conduct a early review of archivesspacelabs and will move clearly abandoned or obsolete code to deprecated.

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 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)

As far as I know, there's currently no automated way to say "this fork is a reference, keep this fork up to date with its parent." Thus, anything forked in to this org will need more or less constant maintenance, or some sort of scripted update mechanism, in order to maintain currency.  Given that this seems primarily intended as a linking mechanism to externally provided code, would it maybe make sense to have the primary entry point into this be a Github Pages page, with a link to each internal/external tool and other explanatory content.  I think the barrier to entry won't be any higher than with a collection of forked repos, and the maintenance burden would be lower.

As per the notes from last time, since we're trying to encourage "as much collaboration, sharing and committing as possible," it might be nice to lower barriers if we had some resources readily available from this space. I'm not suggesting we create any, just point to existing guidelines/tutorials on GitHub lingo, getting things in there, best practices for READMEs (even if we aren't requiring any documentation), etc., who to ask for help, etc.

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.

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. 

Need to decide how labs will work. Will it be forking external projects or encouraging developers 
to work within it directly and transfer existing projects to it? Former is more hands on and will 
require keeping the forks up to date, latter may be harder to get buy­in (devs can also do both 
quite easily by adding labs as an additional remote ­­ should probably encourage that for devs 
who want to maintain control, but can also push to labs). 

About the forks: would we have to keep forks up-to-date? Could that be part of the yearly review to see if things get deprecated (would that be too much)? I like the idea of encouraging devs to make it a remote.

Process / criteria for adding new members: 

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?

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 

repository can be transferred into deprecated two weeks after the initial message.

If there are regular tech team meetings it can be raised. 

___________________________________________________________________________________________________________________________________________________

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
  

Overall 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.