2021-02-23 Meeting Notes

New ranking system proposal

Holly Mistlebauer

• Wants to make the ranking system more transparent

• Current systems results in too many R1 features and can't work them all in

• Have to be planning to implement before you can vote

• All votes will count equally, no weighting

• There will be a cutoff, no changes after that

• Voting will be done before each release because needs change and want to stay agile

• Each library will 100 points to allocate, cannot put more than 20 points on any one feature

• Say there is a top ranked feature that can't be worked on until something else is done - that feature would have to wait until the something else is done, might have to wait for next release

• Teams not governed by Cap Plan will use the rankings in their considerations

• All communications will be announced in Implementers Slack channel

• For dev teams without prioritized features, the PO will determine the work to be done

• Cap Plan will share results with the Community Council and discuss issues that arise

Tom - this will be a public document, no protection against people from outside the community messing with the document

Tom - how will people vote, need to be registered like with governance model voting?

Holly - would not want to be that formal, maybe have one person per institution be an editor

Tom - would also like to see decisions reflected in JIRA

Tom - there have been cases where institutions gave an R1 rating to a features but POs gave it a P2 without explanation.  Would help transparency to know why these decisions are made.

Brooks & Holly - there is a PO Ranking Notes field that can be used for this

Ian - does 'institutions' in this case include vendors, or only libraries?  because as a vendor that does multiple implementations, my feature priorities would be different than those of my partner libraries

Brooks - those kinds of priorities should be communicated through technical or product council and that those bodies should have some direct influence over the plan.

Martina S -  this could be a portion of the assessment, e.g. 70%, the rest would have to come from roadmap planning, e.g. major features

Holly - it would be libraries - if things aren't a priority for libraries the vendors would always be outvoted anyway

Martina S - also networks, as GBV ranks on behalf of its member libraries

Beth - how will libraries that use a vendor participate?

Tod - how would these needs be made known?

Martina S - I am aware that any form of determination is certainly always unfair for someone – but do we think it is okay if every institution, regardless of size and scope of use, has 100 points? Would it be possible to subdivide into keys like "very large", "large", etc.?

Holly - would like to keep it this way for at least the first time and then see if issues like that need to be addressed

Holly - will take these suggestions to the Cap Plan, doesn't expect any concerns from them.  Will come back next week for questions about this, as well as updating on the Juniper release.  Will share final proposal at March 4 PC meeting.  Will open voting on rankings from March 8-19, Cap Plan will review on Mar 22, then give POs two weeks to review, meet with Implementers again on Mar 23, have a final Cap Plan review, back to Implementers on April 20, then present to PC on April 22.

Holly - how do we want the features presented to us?  A spreadsheet separated by Epic and sorted by PO rank might make it easier.

There is a new template for features that POs should use now

Marie - do we rank JIRAs at all now?

Holly - it has been helpful for some institutions to track what is important to them.  Probably should keep ranking through at least the first time we try the new process

ACTION - please review proposal and make comments before next week

Future topics

Receiving workflow demos deferred until Honeysuckle

March 2- Capacity Planning team Juniper update.  See January 28 Product Council minutes or recording for background on how the process works.