Re-org:
https://docs.google.com/spreadsheets/d/1S5C217M3JUZfHSlLarQjAUqCofJ9jMi_C2VIGvyT8KA/edit?usp=sharing
Propose creating / maintaining these organizations:
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.
Maintained by: Program Team, core committers.
https://github.com/archivesspaceplugins/
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.
Maintained by: Program Team, core committers. (plugin committers?)
https://github.com/archivesspacelabs/
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 atyourownrisk basis. Program Team and
other “official” committers can contribute to labs but that does not confer official support to any
project.
Maintained by: Community committers.
https://github.com/archivesspacedeprecated/
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).
need to define criteria and process more here ...
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.
Community committers: Any developer wanting to contribute a project to labs or work within it.
Access to labs (write access).
need to define criteria and process more here ...
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?
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 buyin (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).
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 ...
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.
Minor issues:
Labs branding and making it clear that none of the projects are officially supported.
Next steps:
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
Complete committer group definitions and process for adding members; policies etc.
Announce to list.