Skip to end of banner
Go to start of banner

Adding new requests

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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

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

  • No labels