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.

[bulkrax is not a core component but is now promoted out of Samvera-labs to Samvera and should be listed with product owner.]

bulkrax

Product Owner: Rob Kaufman

Core Components - Requirements

1. Code is stored in a repository in the Samvera github organization Samvera Community 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: Samvera Organizations: Samvera Labs | Guidelines for Promotion to Samvera from Labs

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

Product Owner: Tamsin Johnson

browse-everything

Product Owner: James R. Griffin III

hydra-derivatives

Product Owner: Stuart Kenny

hydra-editor

Product Owner: James R. Griffin III

hydra-file_characterization

Product Owner: Jamie Little

hydra-head

Product Owner: Chris Colvard

hydra-pcdm

Product Owner: vacant

hydra-role-management

Product Owner: James R. Griffin III

hydra-works

Product Owner: vacant

iiif_manifest

Product Owner: Karen Shaw

ldp

Product Owner: Randall Floyd

noid-rails

Product Owner: Justin Coyne

questioning_authority

Product Owner: James R. Griffin III

rubydora

Product Owner: Justin Coyne

valkyrie

Product Owner: Alexandra Dunn

Technical Lead: Trey Pendragon

bixby

Product Owner: James R. Griffin III

samvera-circleci-orb

Product Owner: James R. Griffin III

Technical Lead: Collin Brittle

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.