Improve issues managment

[lilyremigia]

For these I propose the following:

• Set up issue templates for bugs, enchantments, new game support, etc.
• Improve labels.
  • Create labels for each project / area.
    • Ex: "Area: Loader", "Area: Updater", "Area: Configure (Legacy)", "Area: Configure (WPF)"
    • Perhaps separate some of these areas to their own repo and use them as submodules in the main repo?
      • Reducing the size and turning them into digestible units highly likely to improve new developer experience.
  • Create labels for an estimated size of workload.
    • Ex: "Size: S", "Size: M", "Size: L"
• For stale issues, if it cannot be reproduced reach out to issuer. If it cannot be worked on, close issue with "wontfix" or perhaps a "stale".
• Don't forget assignments exist!

[brliron]

Set up issue templates for bugs, enchantments, new game support, etc.

For bugs, this is something we could use. I don't think we need a real template, because things like "steps to reproduce" is something that users will report before being asked and the other things will be in the log files, but a list of instructions, like "try without using thcrap over an English patch", "try with only base_tsa / base_tasofro" and "attach your log files" could be useful.
But overall, we have so much more activity on our Discord than here that I'm not sure this is worth the effort.

For enhancements, I don't really see what we would want in a template.
And for new games support, at least with the current state of our team, the answer will always be "wontfix, we don't have time for that".

For stale issues, if it cannot be reproduced reach out to issuer. If it cannot be worked on, close issue with "wontfix" or perhaps a "stale".

Definitely something we need to get better at. But it takes time, which is time not spent on actually working on thcrap.

Don't forget assignments exist!

I'm not sure about that one. For short ones, we never had the issue of two people doing the same thing. And for longer ones, I think we tend to use them? I also don't want to overuse them because, if we take for example #76 , I self-assigned that one back when I was actively working on SWR and soku support 5 years ago, but I haven't had the time to keep working on that, and the assignment could prevent someone else from working on it, thinking that it's already being worked on.

Create labels for each project / area.
Ex: "Area: Loader", "Area: Updater", "Area: Configure (Legacy)", "Area: Configure (WPF)"

I feel like the lazy way of adding "[component] issue description" or "component: issue description" works well enough.

Perhaps separate some of these areas to their own repo and use them as submodules in the main repo?
Reducing the size and turning them into digestible units highly likely to improve new developer experience.

I don't think it would really help, because, well, these areas interact with each other, so you often need to use 2 or 3 of them when changing something. At the contrary, I think it could hide some of the things you need to see.

Create labels for an estimated size of workload.
Ex: "Size: S", "Size: M", "Size: L"

With all the context around, I think the point is to help newcomers find new issues to work on? And the concept of helping newcomers decide on a new issue could be nice, but Github has a huge banner telling me "hey, there's that 'good first issue' label that we made, we think you should use it", and I think it could be both easier to manage for us, and better for the purpose of helping newcomers.

[lilyremigia]

I feel like the lazy way of adding "[component] issue description" or "component: issue description" works well enough.

Using actual labels would allow for simpler filtering, instead of just having to search. This also would allow you to free up using search for something else. Plus, any newcomer reporting a bug here wouldn't have to worry about the titling as much? As you well known, some prefer C#, some prefer C++.

With all the context around, I think the point is to help newcomers find new issues to work on? And the concept of helping newcomers decide on a new issue could be nice, but Github has a huge banner telling me "hey, there's that 'good first issue' label that we made, we think you should use it", and I think it could be both easier to manage for us, and better for the purpose of helping newcomers.

Yeah, I guess, that would be fine as well.

I don't think it would really help, because, well, these areas interact with each other, so you often need to use 2 or 3 of them when changing something. At the contrary, I think it could hide some of the things you need to see.

Perhaps, true. But take the angle where I'm coming from example: If you are only really interested in the C# code, do I really, really need to have all this?

[lilyremigia]

If nothing else, at least we could have priority labels?