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

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

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

Contributing to ArchivesSpace

• ACTION - Review both and see if we'd like to add to Contributing to ArchivesSpace

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.

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: 

• 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
  
  

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?

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 

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

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

Next steps:

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