2020-06-23 Meeting notes

Date

23 Jun 2020

Attendees

Goals

Meeting with Steering to review the purpose and objectives of the Roadmap Council

Discussion items

Item	Who	Notes
Introductions		Brief Introductions
Roadmap Council purpose and goals	Nabeela	(slides) Roadmaps Alignment
Group Name discussion and suggestions	Rob
Q & A		Liaison to Steering

Notes

Introduction

Goal is to talk a bit about two topics
- The recurring theme of Roadmap Council - what it is expected to do vs. what it is really chartered to address
- If the council is doing what it is chartered to do, then how do we communicate this to the community?
- Charter is not to create a single roadmap for the community, but instead to try and align various efforts within the community

Roadmap Council Purpose and Goals

When the Council started, this was chartered to bring together representatives for service providers, representatives from interest groups, and working groups to align project goals
- Coordinating and communicating regarding community sprints was also a significant undertaking of this group
- Every IG and WG defined their documents differently - the Roadmap Council first saw to try and standardize this by offering templating
- Beyond this, there was a whitepaper published addressing the state of the technology in the community
- Roadmap Council meets every two weeks
Project Management and Community Sprints
- This Council was chartered to assist with managing and aligning these
- 2020 saw an entire year of activity, along with a retrospective
  - Three Goals:
    - Analysis of roadmaps and planning cycles
      - The results of this will be presented during the next Partner Call
    - Facilitating to get code back into core
    - Communicating with the community at large
When we discuss facilitating contributing to core, is this murky or problematic?
- If so, what are the obstacles?
- It comes with challenges given the size of the community, and it will never be trivial
  - There have, however, been real successes
  - User management pieces in Hyku were extracted into a Gem and shared with Hyku and Avalon
    - Who contributed to this?
      - Avalon Team contracted with Notch8, Northwestern paid for the feature with grant funding
    - Roadmap Council makes these efforts known, and interested parties could request involvement and contribute funding or resources
    - The Roadmap Council identified the requirements for work in this case
    - Another Feature: DataCite Integration
      - All community members with this requirement produced a solution for this independently
Some assumed that the Roadmap Council is to coordinate rather than create a roadmap

To what extent should the Roadmap Council invest in aligning IG/WG roadmaps and project roadmaps?
What of individual institutions and their roadmaps for custom Samvera repositories or local Samvera projects?
Community Manager is supposed to be a member of the Roadmap Council
- They are responsible for representing the interests of individual institutions and their roadmaps
- Community Manager clarifies that there might be similar functional requirements for different Samvera projects undertaken by different institutions
If we wish to expand the charter of the Council to address institutional roadmaps, this might be helpful, as this objective is not quite clear in the current charter
Roadmap Council could contribute some of the user stories (in terms of documentation and in order to exhibit the work which was achieved)
- This would also be useful for the induction of the Community Manager

DataCite Integration
- There are currently 7 implementations
- Is there an activity for identifying which of these are being considered for inclusion into Samvera core?
- After looking at multiple implementations, Notch8 has found that the implementations are extremely similar in structure
  - For the next institution which need this, perhaps they can work with the community instead
  - Also, it might also be helpful to have seasoned contributors work in order to "reclaim" projects into Samvera core
Avoiding duplication for future adopters would be very valuable
Gain an understanding and better communicate where the core code base is going
- Additionally, indicating how this might affect other core components?
  - Example: Fedora 4 and Valkyrie
- No one on Steering understood this Council to be chartered to create a single community Roadmap
  - However, where are the boundaries for this? Alignment definitely approaches this type of undertaking between core components and solution bundles
- Discourse
  - Community members are very receptive to polite suggestions
  - Undertaking major solution bundles (Hyku and Avalon), implementers are knowledgeable of Valkyrie
    - There isn't much more coordination required beyond this point
    - The effort is still being directed, and the Hyrax Tech. Lead is engaging with other community developers to remain in alignment with these efforts
- There may still be a communication opportunity for somehow discussing the alignment of the roadmaps between different projects
  - This would really be valuable if the Council could make the Valkyrie work for Hyrax much more visible to the community
    - Path for Avalon is to move to Hyrax, hence, the path to Valkyrie is to move to Hyrax on Valkyrie
    - Avalon still has functionality which Hyrax doesn't, and this still needs to be reconciled in such a way that is compatible with widespread community adoption
Roadmap Council is chartered to coordinate and support "asks"

Council cannot be responsible for proactively identifying who needs an ask, but representatives should be coming to the Council for support
How do we encourage representatives to engage with the Council?
- Perhaps this is a Community Manager responsibility, but what should the path be before we have this role filled?
Past "asks" have not gone through the Roadmap Council
- Steering could help by reiterating that the Roadmap Council is a contact point for support if your project requires resources and support
- Agreed, that would be a good first step
General agreement about what the Roadmap Council is
- Alignment between community project roadmaps
- Coordinating between various institutions in order to reduce redundancy where possible
  - Once a Community Manager role is filled, Roadmap Council would support and assist the Manager

Branding Change
- Council sounds a bit authoritative
- "Roadmap" in the singular implies that there is a single Roadmap for the community
- Currently, one proposed alternative is "Roadmaps Alignment Group"
- Also, perhaps we may charter this as a phased Working Group
  - Perhaps we also state explicitly in the charter that we are not responsible for a single roadmap
  - Working Group might not be the ideal structure, as Interest Groups and Working Groups do eventually come to an end
  - The Core Component Maintenance WG is a recurring WG which recharters on an annual basis using different phases
    - We expect that the Component Maintenance WG will always continue, just with updated charters and new phases
  - Still, down the line, one could technically choose to close the Working Group in the distant future
  - Originally, Interest Groups were meant for loosely-organized discussions, where Working Groups were meant to be project-specific
    - This could be envisioned as an Executive Council, as this still holds more administrative authority
    - Roadmap Council can still revisit the charter and see about borrowing certain aspects of the Core Component Maintenance WG
    - Perhaps adopting the policy of rotation of leadership from other IGs or WGs can be explored
- There is still going to be a subtext where some members may ask for a single community Roadmap, even if there is a branding change and update to the charter
Roadmap Council needs to understand how they can help the Community Manager
- Community Manager should also have an explicit understanding of what is expected of them (with regards to the Roadmap Council)
- Perhaps a small description of this dynamic could be helpful for advertising this role
  - Because this is a distributed job, it is going to be a challenge to meet with and explore the needs of each IG, WG, and institutional member
Should the Council rebrand?
- Just changing the name might not address all of the problems encountered by the Roadmap Council
  - Perhaps another internal Roadmap Council meeting is first needed before the next steps are determined
- Though there has never been a reserved seat for the Roadmap Council on Steering, have a liaison or common member has always been of extreme assistance
  - This can be evaluated after the elections, as the candidates themselves need to be assessed
  - Agreed, this was extremely valuable
How should Steering discuss the role of the Roadmap Council with Partners during the next call?
- Further, how should resource concerns and questions be addressed?
- Two items have been prioritized
  - What is the Roadmap Council/where is the roadmap?
  - Resourcing is important, but this wasn't addressed due to time constraints
    - There was a survey issued by the Roadmap Council to identify where resources are needed
    - This is a separate issue from what is intended to be discussed during the July Partners call
      - Intention is to review the survey results, and to identify the next steps to be taken
      - Less for resourcing, and more concerned with institutional roadmaps, and how alignment can be achieved
  - Some felt that this is exactly the right order, as this information is needed before resource allocation can be approached
- It would still be useful to consider discussing resourcing concerns for the July Partners call
  - Hyrax community work may require further resources as it continues
  - All of these "asks" do happen on their own, and we should please try to consider requesting that interested parties try to attend Roadmap Council meetings
  - (All agreed with this)

Meeting adjourned at 10:02PDT/13:02EDT

Date

Attendees

Goals

Discussion items

Notes

Action items