...
This page outlines at a high level a proposed level model for the organization of the ReShare, including roles, responsibilities and communications channels.
...
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.
...
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
- Features are defined at the highest level by the Product Management group (i.e. “the system must interoperate with ILLiad”) and prioritized
- Product owner and developers place the feature on the timeline, taking into account any technical prerequisites as well as the priority
- Product owner collaborates with SMEs through weekly calls to further define the feature through UX prototypes, data schema, and more detailed stories
- 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)
- 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
- Developers implement, create unit/regression test cases, and document
- PO works with SMEs to evaluate prototypes, either through periodic sprint reviews or more formal sharing. SMEs provide feedback or sign off.
- When the cycle of development and feedback is complete, that feature is complete.