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.]
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.
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:
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.
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?”
Act as point of contact for questions about the component’s goals and path
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.
Actively participate during sprints to provide guidance and prioritization.
Report on whether the component still meets the requirements for being a core component.
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).
Within this branch, please update the following:
Version number (this is often found within lib/[GEM_NAME]/version.rb)