Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Agenda to minutes


Dial (for higher quality, dial a number based on your current location)
US Toll: +1 408 638 0968 or +1 646 558 8656
Meeting ID: 867 230 970
International numbers available:



Discussion items

5 minAnnouncements

German holiday on May 26 - cancel PC?  Written updates from Councils etc...

WOLFcon - early bird registration extended to June 3

Council Elections: PC: 2022 Product Council Election
 - Nomination form

Live now on ERM: Global Banking School (London), National Taiwan University, and South College (Tennessee).

Marshall's whitepaper prompted Sebastian to write a piece about what the open source software methodology means for community work:  Community, not Code, is the True Heart of Open Source - Index Data

40 minPrioritization WG updateMartina Schildt 

Revised proposal for feedback

Widget Connector

Seeking to add tools for SIG (specialist) and institutional (users) rankings, plus using higher-level ranking at the Epic level rather than the Feature level.

For submitting new requests, go through a SIG or product owner to ensure quality submissions (instead of directly into Jira).  The community has an existing mechanism for new apps; can the working group look at this?  Adding issues to Jira is difficult because they may not have a good summary/description and may not have the right size of effort.  Product Owners have no time to review these requests; that is work that can be done in the SIGs.  Requests would move from the SIGs to the POs after the SIG's first review.  Adding requests via the SIGs ensure the idea is larger than the need of only one institution.

Add SIG rankings to the evaluation process; this is an additional field that is added to the calculation in Jira. This would be done regularly at the discretion of the SIG or Product Owner. There would be extensive communication and several weeks to conduct the ranking. For features that go across apps, all related SIGs would rank.  Need clarity about what the ranking represents.  There is a disconnect between making a ranking in the SIGs and the availability of resources.  There also needs to be a mechanism for libraries to contribute their own development back to the project.  How do the rankings feed into the broader roadmap work?  It is important to be clear about how the SIG ranking affects development priorities in order to set expectations properly.

Keep the institutional ranking process; this is one field that is added to the calculation in Jira. The institutional ranking would use the same epic and feature list as SIGs, but not as frequent (institutions one or two times a year versus more frequently for SIGs).  Institutions would use the same tool as the SIGs, and would have more time to rank than the SIGs.  For weighting institution rankings, soon-to-be-implemented and already-implemented would be weighted higher, as would consortia rankings representing many institutions.  Membership in OLF would not factor into rankings.

The working group thought the best unit of ranking is some bundle of features while not an entire epic.  This mechanism hasn't been worked out.

Non-functional requirements (NFRs) would not be ranked, and it isn't clear how NFRs would feed into the development process.

SIGs and institutional rankings would be 1-5.

In addition to the ranking tool, implement a once-a-year survey with open questions (e.g. "10 most important functions"); these would be related to Jira issues by SIGs and POs.

Keep and expand the use of Dashboards in SIGs, especially for broad functional areas including a label for cross-app functionality.

Extensive communication about the ranking process and results is needed.

Near the end of the slides is information about tools to use (including a spreadsheet that compares tools) plus some suggested next steps.

15 minOA Module demoOwen Stephens DemoDetails about the open access request management application, under the direction of the University of Leipzig with input from many institutions.  Libraries are managing some aspect of the process of publishing open access works (mostly articles, but also books), especially where there is some payment to be made (e.g. "Article Publishing Charges" or APCs).  Libraries are not always involved in the process, and in some cases there is institutional funding available for APCs (or from granting organizations).  This app helps institutions manage what they are being asked to support, what moneys are being paid, and where the funds are coming from.  A working group meets weekly just prior to the Product Council meeting, and Knowledge Integration is doing the development.
10 minWOLFcon updates

WOLFcon updates

Action items


Registration for virtual Participation is available:

Chat record

00:05:00	Martina Schildt | VZG:
00:05:37	Anya:	Global Banking School is live on Full Folio
00:05:51	Owen Stephens:	UK Holiday on 2nd June
00:06:00	Anya:	National Taiwan Normal University is live of ERM
00:06:05	Owen Stephens:	(and 3rd June)
00:06:31	Anya:	South College is Live on ERM
00:13:45	Kristin Martin (University of Chicago; she/her):	That sounds like a good way to go to me.
00:15:25	Anya:	South college - is in TN
00:16:06	Anya:	GBS is in London
00:16:35	Peter Murray:	App Ideas page:
00:22:38	Julie Bickle:	Or they get added in Jira, but not as a "feature" (which has a clear Definition and structure for dev work), but as [Name tbd] "new request" ?
00:23:38	Peter Murray:	It was the "APPIDEAS" project in Jira.
00:23:45	Kirstin Kemner-Heek:	That work can be done by the SIG's
00:24:10	Kirstin Kemner-Heek:	From the SIG's to PO's after first review
00:27:42	Charlotte Whitt:	Often new requirements is driven by libraries, who have this requirement as a road blocker for them in order to adopt FOLIO
00:28:37	Owen Stephens:	I like that Sharon
00:37:15	Owen Stephens:	I agree with that Ian - and there's definitely potential for frustration from the SIGs to see things they have prioritised not getting developed (and I think some SIGs are already in this situation)
00:39:18	Kirstin Kemner-Heek:	+1 Martina
00:40:33	Kirstin Kemner-Heek:	That prioritization is the base to decide on development and open up the opportunities for hopefully future developer Teams to get orientation, what is needed most.
00:42:12	Charlotte Whitt:	And also we need to plan work on features, which span over several apps; so the work being rolled out is useful for the implementing libraries, and not just half-baked functionality
00:44:43	Jana Freytag | VZG:	We have discussed, that NFR and basic industry standards should not be part of the ranking but rather something that will go into development automatically as well.
00:44:58	Kirstin Kemner-Heek:	+1 Owen. Prioritizing gaps / needs/ requirements is just one half of a process to get things done. But it is the necessary start.
00:45:22	Harry:	Owen, I think you have that exactly right.  While the priorities help inform interest, it in no way decides what gets worked on next.
00:46:04	Gang Zhou (SHL):	+1 Owen
00:46:23	Harry:	It has influence.  But not a decision maker.
00:47:36	Thomas Trutt:	Sorry, i got tied up.
00:48:17	Kirstin Kemner-Heek:	But development Teams / Stakeholder can base their decisions what they will develop on that Information. That is an indicator what customers want. And other Teams can pick up, what is left over …. it Would be an opportunity to have a transparent process who picks up what - on each Stakeholders own decision. That is not questioned.
00:50:06	Maura Byrne:	Should features fit into epics?
00:50:18	Gang Zhou (SHL):	+1 Kristin
00:51:31	Ian Walls:	I think all this assumes that we have a single pool or resources that are working against a single queue of features/fixes.  I don't think that's realistic in an open source setting
00:51:46	Ian Walls:	different groups are going to have different priorities, and they're free to apply their own resources, and those of like-minded institutions, towards those priorities
00:51:47	Harry:	+1 Ian
00:52:06	Gang Zhou (SHL):	+1 Ian
00:52:13	Thomas Trutt:	That is defiantly true.
00:52:29	Marc Johnson:	Ian, I think that is a really important point. Which becomes even more important when a feature crosses app boundaries and potentially involves multiple teams
00:52:36	Ian Walls:	as a vendor, should I get to the point of being able to contribute code, I'm going to do what my partner libraries need done.  I want to be sure that's given back, but that's where my directive is going to come from
00:53:09	Marc Johnson:	I would also note that development teams don’t tend to make autonomous decisions about what they build. Those decisions tend to come from outside
00:53:19	Kristin Martin (University of Chicago; she/her):	I hear from POs that they want these ranking from both the SIG and the institutions. I'm not hearing that they feel bound, but they want to get input into direction.
00:54:49	Kirstin Kemner-Heek:	Yes, from the Stakeholder who hires then, for example. That happens in our FOLIO Environment. Other Options are possible. As well as that team decide to do something completely different. All this doesn't exclude any other decisions. But helps to keep an overview.
00:56:06	Marie Widigson, Chalmers:	No additions, Martina, it was a very good summary!
00:56:38	Thomas Trutt:	+1
00:57:23	Martina Tumulla:	Thank you Martina, wonderful summary!
01:04:16	Peter Murray:	Huh.  First reaction is that it is an odd choice not to use the existing Users database.
01:05:26	Peter Murray:	Oh, that's fine....just my first reaction.
01:05:34	Alexis Manheim:	just use faculty as a default set of users?
01:09:00	Ian Walls:	I would use an external script to copy User information over to the Authors based on whatever rules the individual library sets forth (patron group, tag, custom field, etc)
01:09:54	Ian Walls:	are the licenses in the OA app not the same Licenses in the License app?
01:12:03	Alexis Manheim:	Can you fund and pay for APCs in a similar way as you can for orders for library materials?
01:13:38	Peter Murray:	I got distracted for a moment, but were you keying in the journal information, or were you searching Inventory?
01:21:54	Marc Johnson:	I believe Owen said they are keyed separately as the journal being published in might not be part of a libraries collection
01:26:23	Ian Walls:	makes sense, thank you Owen
01:28:25	Peter Murray:	I didn't say this at the start of the meeting, but Marshall's whitepaper prompted Sebastian to write a piece about what the open source software methodology means for community work:  Community, not Code, is the True Heart of Open Source - Index Data
01:28:27	Jana Freytag | VZG:	Registration for virtual Participation is available:
01:32:18	Jana Freytag | VZG:	Have to leave for the next meeting. Thank you all for your Feedback to the prio wg. bye