We can now use gitlab issues, how are we going to use them?

[Wolthera]

Hi everyone,

Ben enabled gitlab issues for us in the Krita repository. Reminder
that we *shouldn't* copy any phab tasks, as Sysadmin wants to do the
migration themselves.

That said, I would have liked to take this time to spend some time
discussing how we're going to use the new system as it's a little
different from phab, and even then, some of us have never really used
phab like we used to do. Unfortunately, someone already created issues
before I even knew the issues were enabled. I none the less hope
you'll entertain me, I think it'll be helpful if we pin it down now.

---

I'd already been using issues for the text tool in my personal Krita
fork. It's a little less powerful than phab, because a lot of features
are behind the premium paywal. Still, let's review what we *can* do:

Issues cannot be children of other issues. However, tasks (basically
the same, but no mockups can be attached) can be children of issues,
and furthermore, either can hold todo checklists.

See this issue for an example of tasks as children of a main issue:
https://invent.kde.org/woltherav/krita/-/issues/59

Issues themselves can be organized under labels, milestones or
issueboards. Furthermore, they *can* be arbitrarily linked to one
another. That means we have a 4 level hierarchy available
(Milestones/Issue boards > issues > tasks > todo lists). I think this
will be sufficient, and the limitations will allow us to avoid
hyper-analysis.

The difference between milestones and issue boards is that the former
is more controlled and the latter open-ended.

Here's an example of a milestone (for the text tool):

https://invent.kde.org/woltherav/krita/-/milestones/1#tab-issues

And here's the text tool issue board:

https://invent.kde.org/woltherav/krita/-/boards/9684

As you can see, the text tool milestone has an introduction, with a
flowchart. The flowchart is possible because gitlab can use
mermaid.js. For another example, check the fonts issue
(https://invent.kde.org/woltherav/krita/-/issues/52). I update this
flowchart manually, because for me issues are about *communication*.
If I wanted to keep track of my tasks, I'd just use a paper notebook.

One thing I'd like to point out with milestones is their ability to
allow you to filter which items in a particular label are open and
closed inside the labels section of the milestone.

Issue boards however require use of labels, as that's how their
columns are filled. They're automatic, and gitlab free can only use a
single label to drive a single column.

So we'll need to decide how we're going to use this. We already use
milestones for Krita releases, will we continue this way?
---

We will, aside from deciding on how to use the tools available, also
need to decide on some etiquette. I propose the following:

- You are responsible for the issues you create (that is, any issue
that you create, you're the default assignee). Do not create issues
for other people without their consent.
- Do not create a ton of issues without consulting during a meeting or
the mailinglist at kimageshop at kde.org. This is because big projects
need to be discussed first.
  - The exception to this is issues for platform-related nonsense.
When Apple or Microsoft or Google or whatever decide on some very
novel/annoying new platform thing, or we need to keep track of a known
vulnerability, and something *must* change before the next release.
- We probably should avoid having non-code issues in the
graphics/krita repository. We have a repo for the funding website, one
for documentation, and one for the regular website, and any of those
would be fine. My problem with having them in the coding website is
that we need to use that one the most, and non-coding issues tend to
never close because of their ephemeral nature.

---

I'd like to invite you now to take a look at your own projects, and
think about how you would use the issue system.

- How will we handle really big projects, like platform support
(wayland/macos/windows/android), or the tablet ui?
- What about smaller projects like the panel cutter?
- What about things like 'good first-time issues', 'xsimd porting' or
even bugfixes?
- What would you like to know about other projects? Issues are largely
about communication, so what kind of things would make you feel like
you understand other projects?
- What would you find annoying? Can we have some kind of workaround for that?

-- 
Wolthera