2022-06-29 Meeting notes

Date

Attendees

Martina Tumulla Thomas Trutt Marie Widigson Martina Schildt 

Regrets: Jacquie Samples Michelle Futornick Jana Freytag 

Zoom link: https://openlibraryfoundation.zoom.us/j/88593295877?pwd=Zm53aG1Ga2g5SVV1OFAvK0lMVVVQdz09

Calendar invite: https://openlibraryfoundation.zoom.us/meeting/tZwofuqqpz4iHdMaS6vffyjDAlO5x1_KkNTf/ics?icsToken=98tyKuGgqzIpGN2QuB6ARpw-GYr4b-rxmCVHgqdwnSyzFSZVewnSF-5tZ6ouL_Pb


Discussion items

ItemNotes

To Dos

follow ups 


  • Next steps:
    • meet with Julie   
    • 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?


Decisionsplease see table below

Decisions

DECIDED Group made a decision to propose to PC

TBD Needs decision making

QUESTION There is an open question

TBD PC PC decision needed


TopicDecisionArgumentationNotesGroup status
New Requests
  • 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

What should SIGs rank on?
  • 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

SIG prioritization
  • 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

Institutional ranking
  • 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

Weighting for ranking institutions

  • Implement differentiated weighting for ranking institutions
    • for implementation status
    • for consortia vs. single institution
  • TBD: How? What will the weighting look like?


DECIDED

QUESTION

Ranking values
  • 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


 

Chat


Action items

  •