Purpose

This page outlines at a high level  model for the organization of the ReShare, including roles, responsibilities and communications channels.

Management principles

ReShare manages its work through application of three principles: local control, lazy consensus, and transparency. The intent of these management principles are to enable quick decision making ‘in the field’, while allowing stakeholders to weigh in when necessary.

• Local control: The overall principle means: Developers have responsibility for pursuing the vision of the UX/subject matter experts, but will keep the latter informed and allow for critique/questions. The product owner has responsibility for pursuing the vision and direction of the steering committee, but keep the latter informed.
• Lazy consensus: Lazy consensus means information is made available, but consensus is assumed unless otherwise indicated. If an objection is raised, it is expected that the participants will try to reach consensus explicitly, and only resort to a vote when necessary.
• Transparency: All processes and conversations – development, specification, deployment, and strategic planning – are generally open and available to anyone.

Steering Committee

The intent of the ReShare Steering Committee is to place and maintain ReShare as a solution for libraries for resource sharing, and to generate strategic directions, partnerships, and community. The Committee represents the project to the outside world, negotiates with new potential contributors, ensures external communication channels. It aligns activities across the member organizations. 

Product Management Team

The Product Management Team agrees upon development priorities at the level of features. It takes overall responsibility for the internal activities of the project. Participants in the product management group expressly represent their organization in discussions and decisions about the shared disposition of project resources.

Development roles and processes

Product owner

The role of the product owner (PO) is to serve as the glue between the Product Management Team, Subject Matter Expert Team, and Development Team. The PO schedules and guides functional analysis and UX work and supports building out the high level project plan in Jira (epics, features, high-level stories). He or she formalizes data models, state diagrams, etc., in collaboration with subject matter experts. The PO also serves as a liaison to steering committee. 

User experience designers

User experience (UX) designers work with subject matter experts to create wireframes visually representing features/stories prior to development. They meet one-on-one and in small groups with subject matter experts to learn about current workflows, identify pain points, and collaboratively develop ideas for improvement. UX outcomes include clickable prototypes that represent both the eventual ideal state for each feature or module, as well as short-term versioned prototypes representing realistic stages of development.

Subject matter experts

ReShare subject matter experts (SMEs) are resource sharing librarians with expertise in day-to-day workflows. They may be organized into one or more teams, depending on the needs of the project and current workloads. SMEs meet weekly with the PO and UX experts. Each ReShare partner will suggest membership for the SME team(s), but these teams are also open to participation from individuals not representing any partner organization.

Development Team

The Development Team works from the backlog established by the PO in collaboration with the UX designers and SMEs. Architecture decisions are made collectively under guidance from the technical leads. The team aligns work with priorities set by the Product Management Team, accounting for blockages and best sequencing for development purposes. All code created for ReShare is submitted to Github in a ReShare project/directory structure, within the Open Library Foundation infrastructure. The Development team uses Jira for backlog and task management and Slack for daily communication. The team works on a two-week sprint cycle and meets weekly to plan and review sprints, as well as providing a monthly presentation of new functionality for stakeholders.

Feature lifecycle

1. Features are defined at the highest level by the Product Management group (i.e. “the system must interoperate with ILLiad”) and prioritized
2. Product owner and developers place the feature on the timeline, taking into account any technical prerequisites as well as the priority
3. Product owner collaborates with SMEs through weekly calls to further define the feature through UX prototypes, data schema, and more detailed stories
4. PO/SMEs circulate decisions to partners and the wider community through channels (like a project forum and periodic updates). Any feedback is incorporated. (This is a big part of the lazy consensus model)
5. PO records the output of points 3/4 in the project management tool (Jira) as backlog for developers, interleaving the work with other development priorities
6. Developers implement, create unit/regression test cases, and document
7. PO works with SMEs to evaluate prototypes, either through periodic sprint reviews or more formal sharing. SMEs provide feedback or sign off.
8. When the cycle of development and feedback is complete, that feature is complete.