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