2016-07-18

Proposed reorganization, which is represented in this spreadsheet and in summary below:

• archivesspace = as is
• archivesspace-plugins = official plugin, supported (kept up to date)
• archivesspace-labs = proof of concepts, examples, experiments etc. no support (may not be up to date). may also be the "community" org?
• archivesspace-deprecated = was official, now do not use, obsolete 

This structure is used by Fedora, Hydra, and Islandora. Reasons for a plugin org:

• Single location for all "official" (supported) plugins -- avoids duplication in and out of core.
• Minor benefit: reduce size of distribution (it's getting over 100mb).
• Make it obvious what is a plugin.
• Can have more "open" policy for commit access. Policy TBD (start conversation in committer oversight group).

Also TBD: 

1. Promoting developers to committer status. Criteria for core / plugins (labs can be very open).

2. Promoting projects / plugins to official. Criteria needed ...

3. Criteria for deprecating a repo.

Discussion notes:

• Esmé commented that this structure has worked well for other projects he's involved in such as Hydra and Fedora. In other projects, there has been confusion about the 'externals' repository - but plugins are more clearly defined things in the ArchivesSpace architecture so a 'labs' and 'plugins' area will likely make more sense here.
• There was a good bit of discussion about the difference between the common script repository as discussed in the June call vs. a 'labs' area:
  • Labs could be a place where a paid Aspace developer could share not fully production code / useful tools partly developed - e.g. container checker? Labs could also be a place where designated community contributors share code, whereas the community script repository could just be open to anyone
  • Esmé supported keeping labs & community projects together - the most repos you have, the more confusing things would get. Distinction between labs and community script repository seems fuzzy so would lean toward keeping together.
  • Noah raised a frequently observed sharing use case - orgs sharing plugins where code is very specific to their institution but where others may want to see it as an example or general pattern to follow. Where would these go?
    • Esmé favored an approach of 'labs' only include generalizable plugins. If code is very specific to an organization, that org should keep in their own repository.
  • Patrick raised the point discussed in the June meeting that separation from the official ASpace 'brand' may usefully manage expectations about the support provided (or not provided) to community scripts, etc.
  • Max asked who would administer Labs?
    • Archivesspace staff (or there can be multiple Github repository owners) would have to approve new contributors to the repository; the follow up question yet tbd is just how much of a process is required to be a contributors.
    • It was a agreed that either way, a process would be needed for designating different levels of contributor (e.g. core, community). Having a single place for everyone to work together may increase the feeling of community participation.
    • It was agreed that a key detail it would be good to discuss / feed back on further is how open that Labs space will actually be. It could very well be that an independent common script repository could have a wider scope and/or be more open - e.g. a place for those institution specific script / plugin 'examples.
• Who would support the plugins in the supported plugins repo?
  • archivesspace staff - again, would need to define process a organization who has a plugin they'd like to share and have designated a supported plugin
• DECISION - TAC supported the idea of the re-organization in principle.
• ACTION - Mark Cooper (Unlicensed) to add some details to a re-organization plan that says a bit more about what each of the categories mean - e.g. who might be a good group(s) to admin each area, calling out where additional policy statements may be needed.
• In parallel with or after that plan is set, Mark Cooper (Unlicensed) and Esmé Cowles (Unlicensed) will work on the designated committer guidelines. Decision about the re-org of ArchivesSpace github can be done without the guidelines in place. in fact, it will be useful to have the structure in place as some requirements may vary based on what the area - e.g. full test coverage may need to be required in some areas, simply encouraged in others.
• There is no timeframe and/or deadline by which this re-org needs to happen but sooner would be better.