2022-06-29 Meeting notes

To Dos

follow ups 

• fyi: start of new "finalized" slides: Finalized Prioritization Proposal 2022006

• Discuss feedback from Julie on proposed process

  • Julie went through some live examples

  • tried proposed process on these features:

    • https://folio-org.atlassian.net/browse/UXPROD-3480

    • https://folio-org.atlassian.net/browse/UXPROD-1830

    • feedback document:

  • features status

    • link will be provided

  • prioritization on draft level

  • existing features could be taken back to draft, when teams pick them up; so that they get ranked on in the new process

  • adding a release is in the wrong place on the diagram → check

  • how do we deal with the old features?

    • ignore them → no

    • rank on old features → yes

    • this may have changes

    • new people come in

    • workaround does not work

    • list all, and people can decide whether they would like to rank all

    • find ways to give new members a chance to have a say, without needing to rank all old features

    • activate people more active

• Next steps:

  • meet with Julie  Jun 29, 2022 

  • Walk through open questions and make decisions / add to proposal

  • meet with POs

    • question to POs: do features fit into epics?

    • entering new requests in cases where multiple POs are concerned → choose main focus and "cc" all other relevant POs as part of description → are there other ways?

  • meet with SIGs

  • meet with CC?

  • meet at Wolfcon and use that as final deadline for new prioritization start

• JIRA Questions

  • is there a limit of JIRA accounts?

  • is the voting option in JIRA used? Does that have any impact?

Decisions

please see table below

• Create forms for each SIG and one cross-app form in Confluence 

• New requests are submitted via these forms

• Requester enters descriptive title and description with use cases

• default information is pre-entered, to capture all needed details

  • e.g. Assignee (=PO)

  • SIG label

  • "new_request" label

• New requests should be assigned to a PO (=assignee)

  • in cases where multiple POs are concerned → choose main focus and "cc" all other relevant POs as part of description

  • this option should be added as a separate field

• there will be an automated import to JIRA via API

  • once a week

• These new requests will be added as features with a new, separate status and label “new_request”

• new frequests can be monitored via dashboards

• PO or convener does duplicate check

• PO or convener brings request into SIG for further refinement and discussion

• PO or conevener changes status of request

• if necessary: PO can directly change status without SIG discussion (for urgent cases) → this should not be the standard process

• Confluence is open to everyone

• no account limit

• no expert knowledge needed

• Requests cannot get lost and are easier to track for the providing institution 

• new requests are trackable via dashboards

  • for requester, SIG and PO

• possibility to comment

  • e.g. if others would like to push the request

  • for PO to mark as duplicate

• linkable to duplicates

• history can be kept

• alternative: Add “New request” as ticket type (like feature, story …)

• New requests should be added with a spearate status instead of as a new type → advantage:

  • type would need to change from “New request” to feature after "approval"

  • status change is easier, and nevertheless trackable

How to provide new requests is separate from prioritization process, but has been discussed in context of it.

Recommendation: New requests as well as all other tickets in JIRA should be clear in title and description → for being able to understand what exactly the ticket is about → precondition for being able to rank

Decided

• All features with status

  • open

  • draft

  • in refinement

  • in progress

• NFRs?

• Industry standards?

• same as we ranked before; task was to create a new process around existing tickets

• new institutions should be able to rank backwards and not only new requests

• prevent duplicates

  • prevent that institutions create duplicate new requests because they are not allowed to rank on existing open features

TBD: who decides what industry standards are?

Would that be something the SIG could do?

Decided

question

• Use ranking tool

  • TBD: which one? How?

• frequency: regularly, up to PO or SIG convener

• TBD: duration: several weeks (3 weeks?) to rank 

• after ranking process: calculate one total rank per feature

• cross-app features are ranked by all related SIGs

• Add one field per SIG

  • for the calculated total rank of each SIGs ranking

  • as part of each ticket

• Import total rank into JIRA

• in addition: make variance of ranking available to the community (through the ranking tool)

• extensive communication

• asynchronous prioritization via tool enables all community members to take part

  • no matter the time zone

  • no matter whether there are/can be representatives in the SIG meetings

  • no matter the language barrier

Decided

question

• Use ranking tool - TBD: which one?

  • fields to prioritize should include

    • Priority,

    • Impact on work,

    • Urgency

• frequency: twice a year

• TBD: duration: several weeks (6 weeks?) to rank 

• after ranking process: calculate one total rank per feature

• Use a combination of fields for the calculated total rank:

  • Priority,

  • Impact on work,

  • Urgency

• Keep one field for the calculated total institutional rank as part of each ticket

• Import total rank into JIRA

• in addition: make variance of ranking available to the community (through the ranking tool)

TBD

• Implement differentiated weighting for ranking institutions

  • for implementation status

  • for consortia vs. single institution

• TBD: How? What will the weighting look like?

Decided

question

• will be using 5 ranking levels

• similar to R1 to R5, but clearer in wording for comprehensibility

• TBD: is there a limit to how many R1s an institution can have?

TBD