2016-08-24 ArchivesSpace Github re-org proposal discussion

Owned by Sally Vermaaten (Unlicensed)
Last updated: Sept 14, 2016

Present: 

Apologies:

Minutes: 

Discussed proposal now located on wiki at ArchivesSpace re-org and committer groups proposal. 

Points touched on in discussion included: 

  • Ideas on how code contributors might be designated?
    • Fedora has 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. 
  • How many requirements to impose on plugins / code put in archivesspace-labs? 
    • Hydra only requires a CLA and that the plugin be generic
    • Another project (maybe Islandora? my notes aren't great...) has a roadmap committee that reviews labs contributions to ensure they meet a minimum documentation standard and the code is of reasonable quality
    • Group decided that the priority for ArchivesSpace based on where the community is now is to encourage as much collaboration, sharing and committing as possible. 
    • DECISION - Labs should be open and inclusive with no review, no documentation or other requirements and that institution-specific examples that may be useful templates for others may be shared there. Regular (e.g. yearly) review of labs should be made and abandoned / obsolete code can be moved to deprecated.
  • archivesspace-plugins?
    • Separate plugin committer group probably not needed - program team and core committers can manage moving plugins into this space.
    • Plugins added to this space will clearly need to meet more standards (e.g. coding guidelines, generic utility) than those in labs.
  • What core code committers can do? 
    • They have the ability to merge code into the core
    • 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. 

Actions: