Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

Decisions

Status
colourGreen
titleDecided
Group made a decision to propose to PC

Status
colourYellow
titleTBD
Needs decision making

Status
colourRed
titlequestion
There is an open question

Status
colourBlue
titleTBD PC
PC decision needed

Status
titlerejected
Idea is rejected


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”
  • Pro: new requests 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

Why forms in confluence?

  • Confluence is open to everyone
  • no account limit
  • no expert knowledge needed

Why add requests via form to JIRA:

  • 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

Status
colourGreen
titleDecided