Standard template for creating tickets

Continuing the discussion from Display Family Name before Given Name on patient icons:

Thanks @ouiliam for reporting and ticketing that.

One request: please try to make the tickets more clearly actionable for a developer to pick up. Having a link to the Talk thread is nice, but it’s not enough to just point to the entire thread, and presume that a developer will figure out what to do.

Personally I like to use the following sections, which I think provide a good tradeoff between providing enough info, while being easy/flexible for the reporter:

  • Context (layperson’s description of what you’re asking for and why it matters, possibly mention an implementation or type of user, or link to a Talk thread)
  • Steps to Reproduce (only for bugs; describe exact steps to reproduce it, ideally on the bahmni demo server)
  • Acceptance Criteria (numbered list of each individual thing that should be developed and tested)
  • Open Questions (if you’re not completely sure how this should work, it’s fine to leave some “open questions”)
  • Links, Mockups, etc (obviously if you have these, include them)
  • Dev Notes (if you’re a dev, add anything you know that’s relevant to the code)

Any comments on this? Or should I go ahead and document it on a wiki page? (I don’t think JIRA lets us have default values for the Description field, unfortunately.)

5 Likes

Those sections look good. One other suggestion for bugs (especially those that aren’t reproduced on the demo server) is to specify which version/release of Bahmni is being used.

No indeed the description field cannot be formatted.

However it is possible to customize the entire ticket form and add more fields through a custom window scheme, should we investigate that option on the test project?

It is also possible to decide which fields are mandatory or not.

Otherwise yes, this is a great template idea, more than welcome!

This should be the purpose of the ‘fix version’, I guess that you have experienced that it is not accurate for some tickets?

Not exactly - I agree that’s the best place for it, but in the interest of keeping things simple for the reporter (and increasing the chances that this info is reported), I thought it might be worth including this in the description, rather than asking for other fields to be filled out. Experience has shown there’s often confusion about Affects Version/s vs. Fix Version/s too, so this keeps it simple for the reporter, but likely puts some onus on the core team to update those fields (if they’re used).

1 Like

FYI I finally got to add this to the Issue Tracker wiki page in the Dev Team Reference Manual.

(Having thought about this more, do people think it’s okay to leave this in the Description field, or would we be better off introducing explicit fields for these?