Introduction to the Samvera Core Component Maintenance Working Group

The Samvera Core Component Maintenance Working Group was established within the guidelines of the Samvera Interest Group/Working Group framework to facilitate the community with the active maintenance of existing Ruby Gems and Rails Engines which have been maintained and are actively used by members of the Samvera Community. Unlike other Working Groups, the Component Maintenance WG has been rechartered consistently in a series of “phases”; this has been done in compliance with the IG/WG framework, with each phase having a defined conclusion date, and a discrete number of deliverables.

History of the Working Group

Phase 1
- Chartered initially to run from 01/18 - 04/18 (Spring 2018 Samvera Partners Meeting)
Phase 2
- Chartered to run from 04/18 (Spring 2018 Samvera Partners Meeting) - 10/18 (Samvera Connect 2018)
- Two Community sprints were successfully held
Phase 3
- Initially chartered to run from 01/19 - 04/19 (Spring 2019 Samvera Partners Meeting)
- After discussions at Samvera Connect, charter was extended on 03/01/19 to run instead until 10/19 (Samvera Connect 2019)
- Two Community Sprints were successfully held
- Waffle.io closed May 16th, 2019
- Decided to proceed with GitHub Projects in its absence
Phase 4
- Chartered to run from 10/18 (Samvera Connect 2018) - 04/19 (Spring 2019 Samvera Partners Meeting)

During Phase 1 of the Working Group, a list of technical and administrative requirements were defined in order to provide some mechanism by which to determine whether or not a Samvera project can be considered a Core Component. Further, it was determined by the Working Group at this time that projects which have been reference by the community as “solution bundles” are simply too complex to be considered a component which this WG could reasonably maintain. This includes (but is not limited to) the following projects:

Additionally, it was determined that projects commonly used by the Samvera Community could not be identified as Core Components, unless their core contributors sought to migrate this project into the Samvera GitHub Organization. Examples of these include:

However, beyond these criteria and noted exceptions, Core Components compromise many of the projects which one finds within the samvera GitHub Organization. By the conclusion of Phase 1 of the Working Group, an actively-curated list for the Core Components was published to the Samvera Community Guide (https://samvera.github.io/core_components.html).

Core Component Lifecycle

Much of the effort within Phase 1 and Phase 2 of the Working Group were directed at first defining the requirements for a Core Component, and then mobilizing members of the Working Group in order to ensure that any existing Ruby Gems or Rails Engines under the samvera GitHub Organization either met the requirements, or were deprecated and moved to a separate GitHub Organization. This organization is samvera-deprecated, and is reserved for projects which are no longer actively maintained or used by the majority of the community.

The process of deprecation is not solely undertaken with the discretion of this Working Group, and the Community Guidelines describe the process for this as well (https://samvera.github.io/deprecation.html). The formal process of deprecation does require that a call be made to the samvera-tech Google Group to deprecate the project, and a 30-day window is required in order to provide all community members with the opportunity to intervene and guide the Working Group in ensuring that the project meets Core Component requirements. An example of this process can be found in the following discussion thread: https://groups.google.com/d/msg/samvera-tech/2Ul7fumgJbA/qr9BsZSDAAAJ

Following these initial achievements was the determination of a set of guidelines by which to ensure that projects within Samvera which were under active development could remain publicly accessible and used in production, but also separated from proper Core Components. This organization is samvera-labs, and is reserved for all members in the community with a proper Contributor License Agreement to freely publish and share their own experimental projects.

Further, these efforts defined the steps for a process of promotion, such that should a popular project be developed to eventually meet the community requirements to serve as a Core Component, it could then be moved into the samvera GitHub Organization. As as the case with deprecation, the process for this is also outlined in the Community Guidelines: https://samvera.github.io/samvera_labs.html#guidelines-for-promotion-to-samvera-from-labs. Requests for promotion are also issued to the samvera-tech Google Group, and these typically also include a call for a community member to serve as a Product Owner. Please see one case for such a call: https://groups.google.com/d/msg/samvera-tech/3nR6aWRCsE4/DyO9FzuVDQAJ

Hence, a lifecycle has emerged which yielded the following management workflows:

Lifecycle Process	Initial Project Status	Tasks	Final Project Status
Audit	(pre-existing samvera project)	Updated to meet requirements	samvera
Deprecation	(pre-existing samvera project)	Call for deprecation issued to the community	samvera-deprecated
Promotion	samvera-labs	Updated to meet requirements and call for promotion issued to the community	samvera

At this point in time, there has been no request to extend these guidelines in order to provide for a process by which to ensure that projects which have been moved to samvera-deprecated can be revived/repromoted to samvera. Should there be any interested in addressing such a case, this Working Group would be eager to engage with the interested parties and assist with defining this.

Product Owners and Technical Leads

As an administrative requirement for GitHub projects to remain in samvera or be promoted from samvera-labs, for each project which can be considered a Core Component, there must be a single member of the community who volunteers to serve as the Product Owner of a project. This process consists of simply notifying the community of their willingness to serve as the Product Owner using either the samvera-tech Google Group (https://groups.google.com/forum/#!forum/samvera-tech) or the Samvera Community Slack (https://samvera.slack.com/).

As enumerated on the Community Guide, there are several duties obligatory for the role of Product Owner (https://samvera.github.io/core_components.html#product-owner-responsibilities). However, it should be noted that these need not actually be exclusively addressed by the single Product Owner alone; the Working Group has understood that there are many cases where it is preferable or necessary to permit the Produce Owner to identify and delegate some of these responsibilities to another community volunteer. This has traditionally been someone in the community who has some deep knowledge of the code base for the project, and this role is defined as the Technical Lead. Unlike the Product Owner role, Core Components are *not* required to have a designated Technical Lead.

Documentation

Documentation requirements are explicitly stated within the technical requirements for promoting projects to a Core Component (https://samvera.github.io/samvera_labs.html#documentation-requirements), but it should be noted that there is quite a bit of standardization in the Markdown for these files. As stated in the guidelines, the following files *must* be present in order to become a Core Component:

LICENSE
README
CONTRIBUTING

However, it should be noted that the following files are also typically included within a given project:

SUPPORT
CHANGELOG

Regarding the templates for these, there is no existing, separate GitHub repository which provides the updated text for many of these files. It is recommended that one contact the current chair for assistance in meeting the documentation requirements.

Releasing Gems

Releasing new versions of Core Components is a duty required of the Product Owner, and this does involve some work with the code base itself. The Samvera Community strongly urges that versioning for Core Components follow semantic versioning guidelines (https://semver.org/). This ensures that patch, minor, and major releases clearly indicate to community members and adopters of the potential updates which might be required when updating a specific Gem dependency in a downstream project.

Gem versions themselves are released to RubyGems (https://rubygems.org/), and in order to successfully publish (or “cut”) a new Gem release, one will need certain additional administrative privileges for this. Please freely contact the current chair of this Working Group in order to request these privileges.

While there is not a single, consistent Gem release process for every Core Component, there are a number of common patterns used to simplify the tasks involved. The most common includes the usage of a Rake command `rake release`, which automates the process of generating a new `git` tag for the release, as well as building and publishing the new release to RubyGems. One case is very well documented on https://github.com/samvera/active_fedora/wiki/Release-management-process.

Backlog Management

Another responsibility of the Product Owner to address for a Core Component is the management of the issue backlog for the GitHub project. The manner by which one is to create and track GitHub issues has been left entirely to the discretion of each Product Owner. However, it is quite common to use a GitHub Project Board (please find an example at the following: https://github.com/samvera/valkyrie/projects/2) in order to best organize issues to be addressed by community members or the Working Group during a sprint. Further, it may also be valuable to attempt to explore the usage of GitHub issue labels (https://help.github.com/en/github/managing-your-work-on-github/about-labels), and GitHub milestones (https://help.github.com/en/github/managing-your-work-on-github/about-milestones) in order to more easily organize issues as they relate to any planned releases for a Gem.

Participation

We encourage and welcome all members of the community to contribute in whatever capacity is available to our Working Group, and want to emphasize that one need not commit to membership in order to attend a call for the Working Group. Should there be any questions or requests to improve this documentation, please freely contact us in the Working Group.

Browser not supported