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 Ā Ā
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
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
Topic
Decision
Argumentation
Notes
Group 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?