2024-07-11 Product Council Agenda and Meeting Notes

15 min

Announcements and introduction of new PC members

All

Call for topics for in person Tri-Council meeting at WOLFCon

Introductions
New co-chair needed

• Kristin will rotate off as co-chair

• New co-chair to take on the role needs to be found

Note takers:

• we have 4 note takers rotating

• if someone is interested in taking notes, please let Alexis know

• Kristin Martin will join the note taker team

Liaisons

• Jeremy will represent the PC on Technical Council

Wiki pages

More organization will follow in PC only Slack channel: finding co-chair, liaisons, further note takers

15 min

Developer Advocate update

@Patrick Pace (Unlicensed)

• developer advocate helps developers onboard and overcome any issues

• summarized overview of activities:

  • review developer documentation, learning FOLIO and toolstack

  • Meetings: TC, meetings with TC liaison (Jeremy), developer documentation TC subgroup

  • develop position

  • developer documentation

  • developer mentorship program, incl. brainstorming, exploring, researching, sending a survey

    • planning to have an interview with Library of Australia to learn about their issues during onboarding

• If you have developers who are interested, reach out to Jeremy Huff or Patrick Pace.

• Is there more information about NLA stopping development? The TC scheduled a meeting at a Pacific friendly time. As part of that meeting, there was mention at the difficulty getting developers up to speed with FOLIO. For NLA, it was felt that getting developers up to speed wasn’t productive. This prompted the idea to follow up with the NLA to understand this and learn how to avoid this situation.

25 min

Acquisitions prioritization pilot

@Martina Schildt

The was a pilot to prioritize issues that might be rolled out to other SIGs. The pilot in the Acquisitions SIG was to test a process for the prioritization of issues raised by the community. The process relies on an Implementers Topic Page where anyone can add their tickets and requirements. These are new requirements that people want to be added as new functionality. There is a person who reviews this and brings it to the SIG to learn about the topic and requirements. Then a Jira issue is created for the requirements. People vote for the issues in JIRA. By the number of votes, the developers and PO know the priority of the community. There is no restriction on the voting.

Question: It sounds like a particular library can vote as many times as they have staff. In theory, this can happen. If voting isn’t restricted, could this happen? However, in the feedback, you can see who voted with email addresses. This allows you to see if there are people from the same institution who voted. For this pilot, this didn’t happen.

Comment: This process doesn’t determine what gets worked on but it does highlight why a topic is important for a community or SIG.

Comment: From experience with library wide efforts, it would take a lot of effort to have everyone vote.

Event if you have more than one vote, it could be from staff from different units/areas.

Acquisitions SIG Feedback: Everyone said it was a good progress. PO’s noted that the number of votes was low. The ticket with the most votes is only 12 right now. It might be beneficial to advertise this more widely. The group prefers this easy access for voting. The Acquisitions SIG will continue with this process. There might be improvements to the filters. A cheat sheet is being created to help other SIGs.

Does this take a lot of work? Would this be a barrier? This didn’t happen in the Acquisitions SIG. This might not be a lot of work. You can scope this. Not every ticket is voted on. Coming up with new things to review should be scheduled. Setting up this page and creating the issues does take work. SIGs can do it this way or differently.

We’re using the word vote and vote implies a decision. However we’re taking a survey of the community. In the long term are we creating confusion? Should we use the survey instead of vote? The word comes from JIRA. We should be transparent that that a Jira vote isn’t a final decision. It is there to help the teams prioritize development. Could we adopt a community name for these surveys? We trying to use as much as the existing structure as possible. Can the name in Jira be changed from vote to something else? If we can’t, then we document what a vote means.

Do we need to find a new role or look at new roles? The PC can pick this up. In the Workflows SIG, there are 2 convenors. If you look for 2 volunteers, it’s easier than 1.

5 min

Future topics

All