Samvera Code Repository

The primary Samvera code repository contains the Samvera community’s current consensus on what we are using, maintaining, and recommending. Ideally, this repository only contains code modules that are being actively used and maintained. Anything that falls into disuse should be a candidate for deprecation.

Requirements for a Core Component

1. Code is stored in a repository in the Samvera github organization https://github.com/samvera and meets the requirements for being there.

2. Component has a designated product owner.

3. A participant of the Component Interest Group must have a vested interest in the maintenance of that component, acting as a representative for their institution’s needs.

Maintenance

The Component Maintenance Interest Group is in the process of creating a framework for addressing ongoing maintenance of shared code repositories.

Product Owner Responsibilities

Product owners act as representatives for stakeholders of each component, an organizational force to enable the component maintenance interest group to do its work, and a point of contact for distributing or recording information regarding the component. They are not required to have a deep technical understanding of their component. Their responsibilities are as follows:

1. Ensure a release gets cut.
   • Decide when a release is done, what the version number should be, what will be in a release, ensure the CHANGELOG is updated, and announce the release to the community.
   • Decide what the policy for your component is in regards to backwards compatibility and which versions are supported.
2. Own the Backlog
   • Handle incoming issue labeling
   • Create tickets for security issues discovered by automated tooling.
   • Ensure pull requests aren’t sitting around without any response for a long time.
   • Know what priorities are by being in touch with stakeholders enough to understand what the greatest pain points/desires for features are.
   • Be able to give the Component Interest Group a gauge of how important a set of work is and when it needs to be done. Have a ready answer for “if we could give you a week of work, what would you spend it on?”
   • Be able to find answers for “so and so wants to do this with the library, is that a good idea?”
3. Act as point of contact for questions about the component’s goals and path
4. Ensure there’s sufficient documentation for the component to be useful
   • Doesn’t necessarily have to write the documentation, but should know what’s out there and have an idea of what might need to be updated if the scope changes, etc.
5. Actively participate during sprints to provide guidance and prioritization.
6. Report on whether the component still meets the requirements for being a core component.
   • Meets the criteria here: http://samvera-labs.github.io/promotion.html
7. Recruit any necessary positions for better maintaining their component.
   • E.g a technical lead.

Core Components and Product Owners

Please note that Hyrax is not considered a ‘component’ under the definition used by the CCMWG.

active_fedora

Code: active_fedora

Product Owner: Tamsin Johnson

Vital Statistics:

browse-everything

Code: browse-everything

Product Owner: James R. Griffin III

Vital Statistics:

hydra-derivatives

Code: hydra-derivatives

Product Owner: Stuart Kenny

Vital Statistics:

hydra-editor

Code: hydra-editor

Product Owner: James R. Griffin III

Vital Statistics:

hydra-file_characterization

Code: hydra-file_characterization

Product Owner: Jamie Little

Vital Statistics:

hydra-head

Code: hydra-head

Product Owner: Chris Colvard

Vital Statistics:

hydra-pcdm

Code: hydra-pcdm

Product Owner: Mark Bussey

Vital Statistics:

hydra-role-management

Code: hydra-role-management

Product Owner: James R. Griffin III

Vital Statistics:

hydra-works

Code: hydra-works

Product Owner: Mark Bussey

Vital Statistics:

iiif_manifest

Code: iiif_manifest

Product Owner: Karen Shaw

Vital Statistics:

ldp

Code: ldp

Product Owner: Randall Floyd

Vital Statistics:

noid-rails

Code: noid-rails

Product Owner: Justin Coyne

Vital Statistics:

questioning_authority

Code: questioning_authority

Product Owner: James R. Griffin III

Vital Statistics:

rubydora

Code: rubydora

Product Owner: Justin Coyne

Vital Statistics:

samvera.github.io

Code: samvera.github.io

Product Owner: Andrew Myers

Vital Statistics:

valkyrie

Code: valkyrie

Product Owner: Alexandra Dunn

Technical Lead: Trey Pendragon

Vital Statistics:

bixby

Code: bixby

Product Owner: James R. Griffin III

Vital Statistics:

samvera-circleci-orb

Code: samvera-circleci-orb

Product Owner: James R. Griffin III

Technical Lead: Collin Brittle

Vital Statistics:

Gem Release Process

1. Create a new branch of the following form: git checkout -b prepare-release-3.2.1 where 3 is the major release, 2 is the minor release, and 1 is the patch release (please see Semantic Versioning for reference).
2. Within this branch, please update the following:
3. Version number (this is often found within lib/[GEM_NAME]/version.rb)
4. The CHANGELOG.md
5. Any additional documentation and areas of code
6. Commit these changes (using git commit) and push these to the GitHub repository using git push origin prepare-release-3.2.1
7. Create a Pull Request and request a review from @samvera/maintenance
8. A member of the Component Maintenance Interest Group should approved of and merge the pull request
9. One this has been completed, there are now two tasks left (both can be delegated to members of @samvera/maintenance):
10. The new Gem release can be published to RubyGems 1. Invoke bundle exec rake release 1. This requires that one have an account with the necessary privileges on RubyGems
11. As this creates a new git tag with the version as the tag name, this can be used to draft and publish a release on GitHub
12. Please notify any member of the Component Maintenance Interest Group, and we can assist by announcing the new release to the #devs Samvera Slack Channel and the samvera-tech Google Group.