Skip to end of metadata
Go to start of metadata


The Samvera Governance Working Group is dedicated to creating a sustainable Governance model for the management and oversight of the Samvera Community and related technologies.

Slack channel:    #governance-models

Rules of the Road for Working Groups



Can be found on the child page: Samvera Governance WG Charter.  Below is the timeline as outlined in the charter.

  • Complete a discussion summary document that provides context of the work done to date by  

  • Circulate the summary document to the community on  
  • Develop a first draft of the proposed models  
  • Draft an initial governance proposal by  

  • Solicit community input on the governance proposal between  -  

  • Hold a webinar that we will record to introduce the model some time between  -  
  • Complete a revised proposal incorporating stakeholder feedback by

  • Send a revised proposal to the community on  

  • Circulate a final proposal to the community between  -

  • Partners to hold a vote  -  

  • Adopt a governance model. 

Draft Document and Supporting Content

(see PDF versions of supporting documentation)

The final recommendations

The draft document:

Please submit feedback via the form:

On March 1, the Working Group Co-Facilitators led a Webinar where they presented the contents of the Governance Recommendations document. 

You may review the webinar as streaming content:

For Slides from the Webinar, please use the following link:



Carolyn Caizzi - Northwestern University

Rosalyn Metz - Emory


Ryan Steans - Northwestern/ Avalon


Maria Whitaker - Indiana University

Evviva Weinraub - Northwestern University

Simeon Warner - Cornell University

Michele Mennielli - DuraSpace

Nabeela Jaffer - Univ. of Michigan

Anna Headley - Princeton

Mark Bussey - Data Curation Experts / Samvera Steering Group

Meeting Agendas and Notes

Drafts by small teams

Nabeela, Carolyn, Maria: Formal Contributions

Simeon, Anna, Ryan:  Stable Communications// Coordination Plan

Rosy, Michele, Evviva:  Community defined Roadmap or Plan

Approval for Working Group

Voted on at Partner's Meeting in November

Re-approved in Google Groups:

  • Northwestern
  • Columbia
  • Cincinnatti

More to come...

  • No labels


  1. Does the "governance proposal" necessarily include details on how the community will resource shared work, and specifically software maintenance and development? I would find it difficult to support this group unless that is a stated focus of the proposal. (My understanding is that how we resource this shared work is what got us down this governance path in the first place, so I'm concerned that there's a risk this effort will be focused elsewhere. (smile))

  2. Great question, Mike.  I'll follow up.

  3. May I echo Mike's concern?  My recollection is that all this started in a discussion about how to make our software development "more professional" now that it seems clear there is likely to be a general community move toward Hyrax and, in particular maybe, commercial service providers using it through Hyku.  We all have a real need to understand the process: how we can feed into it (feature requests etc) and what changes might be coming and when that could affect our delivery systems (roadmap).  The more established community would also welcome a clearer view of how materials coming from IGs and WGs get fed into the process (or not), likewise feature requests from users, and who makes these decisions. Behind all this is the need to encourage and sustain software development.  So from a personal point of view, I feel that this WG might usefully take a "bottom-up" approach.  What does Samvera need at the software R&D level to maintain and further the product, and what resources will this take?  Next, how do we reliably put these resources together (both people and $$$) and then, to my mind last, what management structures are needed to organize all this.  During the first round of discussions I sometimes felt that the "models" were coming first, rather than our needs (a more top-down process).

    Somehow, during the last round, these software-related needs got conflated with community concerns which were not, I think, intended to be a primary focus.  The first WG did extensive work on a CAIRO matrix around software matters but did not do the same for the community side of things. Perhaps this group, too, should focus on software-related issues unless and until work goes into a similarly detailed CAIRO matrix about the community. 

    Ideally, to my mind, anything that is proposed will be compatible with an evolutionary (rather than revolutionary) implementation!  Purely personal thoughts...

  4. I'd like to +1 Richard and Mike's comments - especially Richard's "evolutionary vs. revolutionary" comment. I think that there is immediate need for resourcing around maintenance, development, and coordination and that is probably a good starting point for figuring out the bigger picture issues. 

  5. Suggestion to working group - see today's thread on samvera-tech and samvera-communication elists about Hyrax releases (subject line: "FEEDBACK on Hyrax release options").  I think this is an example of our existing practice.   We reach consensus through multiple communication mechanisms - the weekly Samvera Tech calls followed by discussion on e-lists.  Someone initiates that discussion.  Not all the opinion is in yet – we may find it easy in this case to reach consensus or we may not.   Not everyone who has an opinion necessarily offers one.  Are we pretty happy with this process and do we think it is a good fit for our community when making decisions about software releases, or do we think we can improve on this with a more structured approach, such as a program management committee charged with making this decision?  


    1. Another question for the group to consider: if we do think we can improve on this model with a more structured approach, where are the resources to sustain the approach going to come from? I ask this in order to keep this important principle at the forefront of the governance folks' minds: do not add requirements without identifying resources to fulfill the requirements. No more unfunded mandates, please, else we're perpetuating an unsustainable approach where hundreds of people pile requirements on a very small group of people maintaining their software.

      (Note that this isn't intended as subtle criticism of Linda Newman's very good comment!)

      1. From my personal perspective, the WG may not have the weight to fully resolve all the resourcing issues across the board for all activities and initiatives in the community.  I'm personally interested in figuring out a resource model that helps address Linda Newman's concern specifically about collecting input and managing key decisions.  Especially, that we find a way to do that in a consistent and transparent way.  So, I'm not sure the WG can address "how do we get resourcing commitments for enough developers to diversify the contributor pool across all repositories".  I do believe we can articulate a model and corresponding resources that gives us a more transparent and consistent process for gathering input and feedback and ensuring consistent timelines so that key initiatives like Release Scoping & Testing Process, Overall Community Governance, Code of Conduct, Community Naming, etc. can proceed in a more orderly and inclusive fashion without having to be reinvented each time a new topic comes up.  Michael J. Giarlo & Richard Green - does this resonate with what you were proposing as needing appropriate resourcing, or am I off target?

        I think the current discussion of "what constitutes a breaking change?" is a good example of the type of community discussion that I'd love to see take place in a little more structured and inclusive manner.  Through no one's fault or ill intent, that discussion is taking place in multiple threads in multiple locations that make the outcome likely to seem like the result of back-room-horse-trading rather than community consensus.  

        I recently found this post which seems particularly relevant to our current work:

        List discussions are unlikely to give a clear picture of the community as a whole for several reasons. They favor people who like to argue, those who are more articulate or have more experience in English (or whatever language the discussion is in), and those who feel like they're in the "in" crowd and will have a popular opinion. Finally, they hide how many people are in agreement with someone who speaks up.

        From 5 steps for making community decisions without consensus - which, despite the title, suggests that consensus should always be the initial goal (smile)