Remove 'new-task' GitHub template

[yuvipanda]

Too many options here was a bit overwhelming for me. I
am not sure what a specific 'Task' label gives us over
just blank issues.

[yuvipanda]

@choldgraf I'm trying to go through and look at processes where I'm overwhelmed with the amount of choices, and trying to change to fit.

I'm also not sure if 'Goal' is helpful anymore, so we should consider removing that too.

[sgibson91]

I like the idea of having a template that nudges me to describe the problem and think about a possible pathway forward, but I do also find the number of choices overwhelming. I almost always choose "New Task" though because it feels low down on the list of importance and, therefore, less disruptive if I generate a few over the course of a single working day (I view "Tasks" like "To-Dos"). The exception to my thinking here is the "New Hub" template, which is pretty well scoped I feel.

[yuvipanda]

@sgibson91 ya I find the new hub and incident report templates helpful. I use 'blank issue' similar to how you use task. May I suggest we remove everything except new hub and incident report?

[sgibson91]

I'd quite like some kind of template for these general things just to avoid blank issue bodies and provide that scoping nudge. What do you think of the Turing Way's "General" issue template? https://github.com/alan-turing-institute/the-turing-way/blob/master/.github/ISSUE_TEMPLATE/ISSUE_TEMPLATE.md

[yuvipanda]

@sgibson91 I like that template! I agree that templates are helpful - I mostly just want to reduce the number of them!

[sgibson91]

I mostly just want to reduce the number of them!

Totally agree with you there!

[damianavila]

So, you/we are proposing to have 3 types of issues: New Hub, Incident report, and New Issue (with some templating), and then we use labels for enhancement, task, discussion, etc?

[damianavila]

Well, actually looking at #595, do we need one for Debriefs?

[choldgraf]

What if we took the following approach:

• Remove the task github issue template
• Encourage a team practice of:
  • If the new issue is sufficiently complex, encode it as an enhancement/deliverable by using the enhancement issue template. This way we can track the issue as part of our development workflow.
  • If the new issue is not complex, try to find a "tracking deliverable issue" and add it as a task. This way we can track it as part of broader priorities and deliverables to work towards.

Here I think we will have to strike a balance between "having millions of issues" and "having issues that are extremely large and overly-scoped". But in my experience oftentimes small-ish tasks can often be categorized as part of broader efforts, so we should track them as-such rather than creating different issues for them.

edit: we may also gain a better intuition for this balance as we try out the "Deliverables Backlog" approach described in 2i2c-org/team-compass#188 - I think that we will build over time a good feel for issues that are "too tiny to be on the deliverables backlog"

This is also related to 2i2c-org/team-compass#188

[damianavila]

Encourage a team practice of

That the difficult piece 😉 .
I like the proposal but I think it would be difficult to play it for real. People usually open issues quickly as a response to something they find, they think, etc. The additional step of looking into other big "home" issues will most likely discourage people to open issues at all (because they will miss time or they think they will do it later and forget) or encourage people to avoid that step that will result in a no practice at all. In that scenario, I would prefer people to open issues as easily as possible and then set up aside some specific time to curate those issues.

[choldgraf]

@damianavila though in those cases, they could always open up a blank issue, no? I agree that we don't want to discourage the creation of issues in general, though we definitely do want to encourage greater signal to noise.

This could also be something that more time spent in refinement etc could help with. Perhaps any new issue should include a needs-triage label that could be used as a signal that somebody should make sure it's got the proper structure etc?

[damianavila]

@damianavila though in those cases, they could always open up a blank issue, no?

Those are back holes 😉 .

though we definitely do want to encourage greater signal to noise.

I totally agree with that.

This could also be something that more time spent in refinement etc could help with

Yes... what I am saying above is trying to do the refinement after the issue is created and not ask for that at the time to create the issue (I see looking for a parent issue as a sort of refinement).

Perhaps any new issue should include a needs-triage label that could be used as a signal that somebody should make sure it's got the proper structure etc?

I would assume every new issue needs-triage (without the need of a label) until we know it is ready to live standalone (and maybe that is the time to assign a label) or as a task in a parent issue.

[choldgraf]

So, how should we relate that to this PR? I agree with you that blank issues are basically black holes, though the template that this PR is removing is just this markdown:

# Summary

<!-- What is the context needed to understand this task -->

• a label

so it feels like that is not a lot of structure anyway, and I'm not sure that we gain much by having a template for this. Does that make sense?

[yuvipanda]

I'm on the same page with @damianavila. Extra decisions to be made at issue creation time add impedence to issue creation, especially since often issues are created in a batch.

We can add a 'needs-triage' label by default to all blank issues?

[sgibson91]

so it feels like that is not a lot of structure anyway, and I'm not sure that we gain much by having a template for this

I'm actually amazed that this template isn't something like

# Summary

<!-- Description... -->

# Actions to be taken

- [ ]
- [ ]

That's the kind of structure I'd want. Or the Turing Way template I linked above.

[choldgraf]

How about we combine a few of the ideas above into the following issue templates:

• New Hub
• Incident Report
• General Issue

We keep New Hub and Incident Report the same as they are now. We combine our current templates for New Goal, New Task, and Enhancement (AKA deliverable) into the following General Issue template (inspired from the Turing Way):

<!--
Please complete the following sections when you open an issue. You are encouraged to keep this top level comment box updated as we learn more about the issue. If you have write access to the repository please also assign the appropriate label (or labels) to your issue.
-->
### Summary

<!-- Please provide a detailed description of the change or addition you are proposing, or the question you're asking. Please provide as much context as possible and link to related issues and/or pull requests. If this issue is related to a bug, include information about how to reproduce it.
-->

*Lorem ipsum dolor sit amet, consectetur adipiscing.*

### Tasks to complete

<!-- We suggest using bullets (indicated by * or -) and filled checkboxes [x] here -->

- [ ] *Lorem ipsum dolor sit amet, consectetur adipiscing.*
- [ ] *Lorem ipsum dolor sit amet, consectetur adipiscing.*

---

### Updates

<!-- To avoid that others have to read through the full thread of comments, please update the initial issue with important updates (e.g. decisions taken) regularly. You can update the task list and summary above directly (this is encouraged!) or add new information below in this new section.
-->

*Lorem ipsum dolor sit amet, consectetur adipiscing.*

I could see value in keeping a bug template as well, but don't feel strongly if people prefer to have lower N issue templates

[choldgraf]

Hey all - I didn't want to lose track of this PR, so I've opened up a new PR to supercede this one. What do folks think? #619

[yuvipanda]

Thanks for opening #619, @choldgraf! I'll close this in favor of that.