Public Mailing List

Big internal discussion ending with decision to shut down the public mailing list
- Issues with fragmentation, burden of managing spam, some people (esp. Hudson Malongo) not sure if they can participate
Given public response, we need to settle on a public mailing list
- Need to clarify channels of communication
- Need to share burden of managing list
- Need more productive way for people to file bug reports, preferably using JIRA instead of a mailing list
- Need to do a better job of announcing changes to the community, preferably getting community feedback before making big changes

GitHub Organizations

We should create one or more GitHub organizations for plugins and related projects
Should be very clear about the purpose of each GitHub org and level of commitment of the ArchivesSpace Dev Team
- ArchivesSpace (https://github.com/archivesspace/) -- core application code and related projects (report tools etc.). CLA required.
- ArchivesSpace (https://github.com/archivesspace-plugins/) -- officially supported plugins maintained and tested for compatibility with each release by the ArchivesSpace development team. Contributions here would have same licensing requirements as for the main organization. I would personally prefer this approach (separate org for official plugins)
  - OR just continue the process of bundling “official” plugins with ArchivesSpace itself?
- ArchivesSpace (https://github.com/archivesspace-labs/) -- community projects, relaxed contribution process. No CLA required, no dev team responsibility to maintain. But it could provide a focal point for community collaboration and shared projects. Would be useful if there was a defined path for getting from “labs” to “plugins” or the main repository in the case that it would be generally useful and important to have the functionality included in ArchivesSpace and supported by the core development team.
However we move forward (just “labs”, or “plugins” + “labs”) eventually we’ll (or someone will) need to send the message out about the new “organizations” and how to get involved.

Following on from the GitHub organization discussion, we should improve plugin organization and testing:

plugin versioning to minimize the chance of using incompatible / untested plugins per release version of ArchivesSpace.
a plugin testing framework that is robust (not depending on Travis or other tools that may intermittently fail)
reducing the number of plugins in the core distribution to the bare minimum
a way to indicate which versions of plugins work with which versions of ArchivesSpace