Issue tracking labels & types

[lkstrp]

After the discussion should we start with something classic like this?

Issue Types:

• Key Feature: (final functionality a user wants) - high level used for Roadmap - it's nice if you tie Issues to Key Features
• User Stories: specific requests from users - from the oet-viz repo but I just added a feature request from a random user - I'll add more as I do interviews with TSOs
• Feature: A feature (based on Key features) which a developer can act on .
• Chore: Maintenance with no user facing change: deps, CI, refactors, build and project meta (like this one)
• Bugs: Bug reports

Tags:

• priority
  • priority:high
  • priority:low
  • medium I wouldn't tag, that's just the default
• needs (something is currently blocking before this issue can be tackled)
  • needs:discussion: Requires discussion before further action
  • needs:info: Clarification about behavior needed to assess issue
  • needs:revision: PR requires revision based on review feedback
  • needs:triage: Issue that has not been reviewed by the maintainer
• area
  • area:frontend
  • area:backend
  • ...
• Contributor signals (the usual tags, but probably we don't need them yet and should get rolling first)
  • good first issue
  • help wanted
• duplicate, maybe user question

We probably don't need to use all of them, but mainly get Issue Types, area and needs right. And from that we see how it goes. What do you think @clizbe @shantiii @KristijanFaust-OET @mikoding9 ?

[clizbe]

I'm fine labelling Features, Chores, and Bugs, but do you want them on the same level as Key Features & User Stories? My idea of that 3-way split was to sort the project board. Is it convenient to have Features, Bugs, and Chores in separate sections (5-way) or one list (within 3-way)?

Option 1

• Feature
• Bug
• Chore
• Key Feature
• User Story

Option 2

• Issue
  • Feature
  • Bug
  • Chore
• Key Feature
• User Story

[clizbe]

A different Priority list I've used before:

• NOW - current work
• Soon - upcoming
• Eventually - will definitely do it, but not soon
• Nice to Have - maybe won't do it

Don't know if it's more effective, but thought I'd throw it out there.

[lkstrp]

There are no nested issues types in GitHub. So option 2 only works with tags, which will look more chaotic. And the ones below we have anyway already, since you define them org wide

NOW - current work
Soon - upcoming
Eventually - will definitely do it, but not soon
Nice to Have - maybe won't do it

Happy to adjust the tags here. I would just stick to the default, which is none. Otherwise, it is a bit polluting. It is also a bit redundant now, since we can use swimlanes in the projects and assign people for that

If you give it a go @clizbe, I can setup the types and tags, and we see from there

[clizbe]

@lkstrp I added the Area column. Lemme know what you think.

[clizbe]

Yeah I assumed we wouldn't do nested but use a different column.

Ooh I haven't seen swimlanes yet.

[lkstrp]

For Area we wanna use labels. Not just a project column. Same for the types, there we should use Issue Types. Extra project columns don't show up in the issue list and don't give you more overview in the issue list/ you can't query by them

See here

vs

[clizbe]

But if we move the Types to a label, I can't use it for the swimlanes... or we make it redundant?

[lkstrp]

You can. You just group by type instead of category. I just changed that in the project. If you wanna stick to category, I can also just use the types for your issue category. And the rest we ignore and they dont have a type, is a bit less clean but also works. As a dev I just wanna quickly see what I can ignore

[clizbe]

I think we should keep Categories for the swimlanes and then we can add whatever Labels/Types you like. And maybe add workflows that autolabel if there's redundancy.

Or maybe we don't need the swimlanes...

[clizbe]

Btw are others also using the Project? If you're only looking at the Issues on PyPSA-App, you don't see all the User Stories from the other repo. We could migrate them if we need to.