Template for tickets

[kristinenielsen]

After reflection on our development process, Dawn, Sam and I talked about having a feature request template in github so that every time we create a new ticket, we are asked to fill in a certain set of questions.

Here is a first suggestion for what the ticket template could include. For the assignees, can you please review and in the comments below write your feedback and then unassign yourself. Thanks

Suggestion:

Description of feature/ functionality

(Be sure to include the reasoning if this is not part of a bigger project. Link to spec, notion page, Zeplin etc)

Risks & dependencies

(Consider customer facing, internal and deployment)

Acceptance Criteria

(What needs to happen for this ticket to be closed?)

Estimation of dev task size

• [ ] Small
• [ ] Medium
• [ ] Large

Who needs to test this?

• [ ] Dev
• [ ] UI
• [ ] UX
• [ ] Data science

[jdu]

We have this set up in RoRi already. When you try to create an issue in the repo it presents you with three options https://github.com/wellcometrust/rori/issues/new/choose

[jdu]

[SamDepardieu]

That's pretty cool and easy to implement, I'm all for it 👍

[dd207]

This template looks right to me @kristinenielsen. It's got the questions we need to ask to create clarity across the team.

[lizgzil]

general question - what is the process of filling in a feature request template, do they fill it in in an email to us? I take it it is different from adding an issue to the repo?

I would say add a check box for a data scientist to test it, since there are data science functionalities that people might want to add (e.g. add a new metric output to the evaluation).

[kristinenielsen]

yeah good shout @lizgzil, i've added data science as a box in testing :) it will work so that everytime you click on new issue it will be pre-populated with the template and then you can fill in e.g. the acceptance criteria and check the tick boxes - so it's still the same process as adding an issue/ticket to the repo

[lizgzil]

@kristinenielsen In the case where someone noticed some weird results/incorrect functionality and suspected a bug in the code, what would we want them to do? Because if they tried to open an issue this template wouldn't quite fit with how to describe the bug. In a way a bug fix might be described as a new functionality, and most of the sections are still needed, it's just 'risks and dependencies' that seems irrelevant.

Not sure what the solution is really, but here is a nice bug report template (scroll down to 'Original bug report') https://github.com/docker/for-mac/issues/3499 with expected and actual behaviour, this isn't great, but my suggestion is something like:

Risks & dependencies

(Consider customer facing, internal and deployment. Ignore if reporting a bug.)

Expected & actual behaviour (if reporting a bug)

(Include logs of actual behaviour where possible and describe the expected behaviour)

[SamDepardieu]

We can have a different issue templates for bugs :)

[lizgzil]

@SamDepardieu ah ha!

[dd207]

Was this implemented @SamDepardieu I can't see it in the issue templates.

[dd207]

I'm re-opening @SamDepardieu as I can't see this implemented anywhere. I've added it to next sprint.

[SamDepardieu]

@dd207 I opened this -> #597 to fix the "ehancement proposal" template. Is there other issue template you want me to update?