V | Adding new requests

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

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

REJECTED 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

DECIDED