<div dir="ltr"><div>I've been using gitlab for some of my side projects, obviously on a much smaller scale than Krita, but I hope it'll be a good fit for us once we all get used to it.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Boards, Issues, Tasks, Milestones and Labels<br></blockquote><div><br></div><div>It took me a little while to get used to the workflow here, but here's how I tend to think about this:<br></div><div><ul><li><b>Boards</b> are best for representing a <i>pipeline </i>of <i>issues</i> and <i>tasks</i>. Kanban boards were created to support manufacturing pipelines, and so ideally tasks should "flow through" the board from stage to stage until completion. (For example, we might have a stage for "idea", another for "design", another for "implementation", and another for "polish". Issues and tasks flow through this pipeline from left to right, beginning as a mere idea, to becoming something polished and eventually completed.)</li><li><b>Issues</b> represent <i>bigger ideas</i>, such as problems that need to be solved, large scale changes that need to be made, or anything that might need to be broken into individual <i>tasks</i>. Ideally issues will be things with a concrete solution or conclusion, so that we don't clog the pipeline with evergreen issues that will never be solved.  ("Update Krita for Qt6" is a good issue, because we can set a concrete goal. "Optimize Krita" is a bad issue because it's an ongoing, general thing that'll never be solved.)<br></li><li><b>Tasks</b> represent smaller, more concrete and actionable ideas, which are the individual things that we need to do to solve an <i>issue</i>. Tasks should be clear, concise, and concrete steps. We define the issue first, then we break it into tasks, delegating those tasks if needed. There shouldn't be any ambiguity about what needs to be done to finish a task. We can think of tasks as a glorified checklist. (In fact, I believe you can convert checklist items within an issue into a task, which is a good way to go about it, imo.)</li><li><b>Milestones</b> are entire projects, planned versions or points in time. (Like "Krita5.3", "Krita6", "GSoC2025", "CompanySponsoredProject2026", "AndroidStableRelease", your "TextToolProject" example, etc.)</li><li><b>Labels</b> are basically just tags, like we're already using, but also applied to issues and tasks. Each column in a board is tied to a label, so it's important to have labels for each step in the dev pipeline too. ("Idea", "Design", "Implementation", "Polish", "Performance", "Feature", "Enhancement", "Bug", "Refactor", "CI", "UX", "Meta", "Marketing", are some ideas off the top of my head.)</li></ul><div>Of course, that's just my interpretation and experience. We obviously can't expect to nail all of this stuff right away or get anything perfect.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I update this<br>
flowchart manually, because for me issues are about *communication*.<br>
If I wanted to keep track of my tasks, I'd just use a paper notebook. <br></blockquote><div><br></div><div>I agree with this, but another part of creating tasks is delegation, which is something that's pretty hard in FOSS projects where we're all working asynchronously, so to speak.</div><div>Ideally breaking projects into issues, and issues into tasks, will help us share work and work together on things.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Issue boards however require use of labels, as that's how their<br>
columns are filled. They're automatic, and gitlab free can only use a<br>
single label to drive a single column.</blockquote><div><br></div><div>One nuance here is that we don't <i>have to</i> have a board column for each label. </div><div>In other words, <i>every column needs a label, but not every label needs a column</i>.</div><div><br></div><div>Personally, I'd argue it would probably be a bad idea to create a column for every label anyway, because it would make the pipeline less clear.</div><div>My recommendation would be to create as many labels as we think make sense, but to try to minimize the number of board columns we start with.</div><div>(It's easier to start simple and add layers of complexity over time than it is to start complex and simplify later, you know?)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">We already use<br>
milestones for Krita releases, will we continue this way?</blockquote><div><br></div><div>I think this is certainly a good way to go.</div><div><br></div><div>Milestones for "events" and "projects", including Krita releases, large projects, etc.</div><div>Boards for "pipelines" where things go from stage to stage.</div><div>Issues for concrete problems or smaller projects.</div><div>Tasks for individual concrete...well, tasks.<br></div><div>Labels for categorizing everything as much as we want (though again, <i>start simple and add over time</i>!)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">You are responsible for the issues you create (that is, any issue<br>
that you create, you're the default assignee). Do not create issues<br>
for other people without their consent.</blockquote><br></div><div>Ok<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Do not create a ton of issues without consulting during a meeting or<br>
the mailinglist at <a href="mailto:kimageshop@kde.org" target="_blank">kimageshop@kde.org</a>. This is because big projects<br>
need to be discussed first. <br></blockquote><div><br></div><div>I agree when it comes to issues. </div><div><br></div><div>With the exception of creating a <i>reasonable number of tasks</i> for your issues as needed. <br></div><div>Let's just try not to spam or flood the boards with a million things. </div><div>Start with a checklist inside and issue and upgrade them to tasks as needed.</div><div><br></div><div>We should try to really value that clarity and organization of the board. <br></div><div><br></div><div>Breaking problems into a few manageable chunks is good organization.</div><div>Breaking problems into a thousand unmanageable grains of sand is bad organization.</div><div><br></div><div>In a perfect world, we can all look at the board and have a decent sense of what's going on, which means finding the right balance between big ideas and smaller ones.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">We probably should avoid having non-code issues in the<br>
graphics/krita repository. We have a repo for the funding website, one<br>
for documentation, and one for the regular website, and any of those<br>
would be fine. My problem with having them in the coding website is<br>
that we need to use that one the most, and non-coding issues tend to<br>
never close because of their ephemeral nature.</blockquote><div><br></div><div>Fair enough.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">How will we handle really big projects, like platform support<br>
(wayland/macos/windows/android), or the tablet ui?</blockquote><div><br></div><div>Platform support is an ongoing thing, so it's kind of abstract. Same with tablet UI.<br></div><div>Like you said above, we want to make sure that things are concrete and not too ephemeral. <br></div><div>Other than Labels, everything that we add should have a "finish line", or it'll just be there forever.</div><div><br></div><div>For example: </div><div><ul><li>"Android" would be a <i>bad milestone</i>, issue or task (because what does it mean for "Android" to be done?)</li><li>"Android" would be a <i>good label</i> (so that we could tag issues and tasks as being relevant to android.)</li><li>"Android" would be a <i>bad board column</i> (because it doesn't represent a stage in the development pipeline that issues or tasks move through).</li><li>"AndroidStableRelease" or "AndroidStable-v1", however, would be a good milestone because we could consider that to be the first officially stable version for Android (and something we could use to organize a number of issues and tasks).</li></ul><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What about smaller projects like the panel cutter?</blockquote><div><br></div><div>Ideally I think most projects should be issues, so that we can associate them with a specific milestone.</div><div><br></div><div>So, in my opinion, we make "Panel Cutter Tool" an issue, we populate it with a checklist of pseudo-tasks (which we can convert to proper tasks as needed for elaboration or delegation), and we associate it with a milestone like "Krita5.3".</div><div><br></div><div>With that said, I don't necessarily have a problem with occasionally creating a milestone for big projects like you've done for the text tool. The only downside to that (that I can see) is that we can't associate it with a specific release milestone, afaik.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What about things like 'good first-time issues', 'xsimd porting' or<br>
even bugfixes?</blockquote><div><br></div><div>"JuniorJob" and "Bug" should be labels.<br></div><div>"XSIMD Porting" should probably be an issue, with a "Performance" label, and a associated release milestone.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What would you like to know about other projects? Issues are largely<br>
about communication, so what kind of things would make you feel like<br>
you understand other projects?</blockquote><div><br></div><div>I'd like to know what a project is, who is working on it, how far along it is, what it pertains to, and when it's planned to be finished. <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What would you find annoying? Can we have some kind of workaround for that?<font color="#888888"><br></font></blockquote><div><br></div><div>The only thing I would find annoying is adding too much, too soon.</div><div><br></div><div>There's a fine line between design and over-designing (and I'm just as guilty of this as anyone else here!) <br></div><div>So, I'd like it if we could start with something simple, and add complexity over time as needed.</div><div><br></div><div>I realize that's really subjective and somewhat vague, but basically if we add things as needed I think it'll be better than getting too ahead of ourselves and trying to preemptively add too many things to the point where it becomes overwhelming for all of us.</div><div><br></div><div>- Emmet<br></div><div><br></div></div><div> <br></div></div><div> </div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Jul 21, 2025 at 4:54 PM Wolthera <<a href="mailto:griffinvalley@gmail.com">griffinvalley@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi everyone,<br>
<br>
Ben enabled gitlab issues for us in the Krita repository. Reminder<br>
that we *shouldn't* copy any phab tasks, as Sysadmin wants to do the<br>
migration themselves.<br>
<br>
That said, I would have liked to take this time to spend some time<br>
discussing how we're going to use the new system as it's a little<br>
different from phab, and even then, some of us have never really used<br>
phab like we used to do. Unfortunately, someone already created issues<br>
before I even knew the issues were enabled. I none the less hope<br>
you'll entertain me, I think it'll be helpful if we pin it down now.<br>
<br>
---<br>
<br>
I'd already been using issues for the text tool in my personal Krita<br>
fork. It's a little less powerful than phab, because a lot of features<br>
are behind the premium paywal. Still, let's review what we *can* do:<br>
<br>
Issues cannot be children of other issues. However, tasks (basically<br>
the same, but no mockups can be attached) can be children of issues,<br>
and furthermore, either can hold todo checklists.<br>
<br>
See this issue for an example of tasks as children of a main issue:<br>
<a href="https://invent.kde.org/woltherav/krita/-/issues/59" rel="noreferrer" target="_blank">https://invent.kde.org/woltherav/krita/-/issues/59</a><br>
<br>
Issues themselves can be organized under labels, milestones or<br>
issueboards. Furthermore, they *can* be arbitrarily linked to one<br>
another. That means we have a 4 level hierarchy available<br>
(Milestones/Issue boards > issues > tasks > todo lists). I think this<br>
will be sufficient, and the limitations will allow us to avoid<br>
hyper-analysis.<br>
<br>
The difference between milestones and issue boards is that the former<br>
is more controlled and the latter open-ended.<br>
<br>
Here's an example of a milestone (for the text tool):<br>
<br>
<a href="https://invent.kde.org/woltherav/krita/-/milestones/1#tab-issues" rel="noreferrer" target="_blank">https://invent.kde.org/woltherav/krita/-/milestones/1#tab-issues</a><br>
<br>
And here's the text tool issue board:<br>
<br>
<a href="https://invent.kde.org/woltherav/krita/-/boards/9684" rel="noreferrer" target="_blank">https://invent.kde.org/woltherav/krita/-/boards/9684</a><br>
<br>
As you can see, the text tool milestone has an introduction, with a<br>
flowchart. The flowchart is possible because gitlab can use<br>
mermaid.js. For another example, check the fonts issue<br>
(<a href="https://invent.kde.org/woltherav/krita/-/issues/52" rel="noreferrer" target="_blank">https://invent.kde.org/woltherav/krita/-/issues/52</a>). I update this<br>
flowchart manually, because for me issues are about *communication*.<br>
If I wanted to keep track of my tasks, I'd just use a paper notebook.<br>
<br>
One thing I'd like to point out with milestones is their ability to<br>
allow you to filter which items in a particular label are open and<br>
closed inside the labels section of the milestone.<br>
<br>
Issue boards however require use of labels, as that's how their<br>
columns are filled. They're automatic, and gitlab free can only use a<br>
single label to drive a single column.<br>
<br>
So we'll need to decide how we're going to use this. We already use<br>
milestones for Krita releases, will we continue this way?<br>
---<br>
<br>
We will, aside from deciding on how to use the tools available, also<br>
need to decide on some etiquette. I propose the following:<br>
<br>
- You are responsible for the issues you create (that is, any issue<br>
that you create, you're the default assignee). Do not create issues<br>
for other people without their consent.<br>
- Do not create a ton of issues without consulting during a meeting or<br>
the mailinglist at <a href="mailto:kimageshop@kde.org" target="_blank">kimageshop@kde.org</a>. This is because big projects<br>
need to be discussed first.<br>
  - The exception to this is issues for platform-related nonsense.<br>
When Apple or Microsoft or Google or whatever decide on some very<br>
novel/annoying new platform thing, or we need to keep track of a known<br>
vulnerability, and something *must* change before the next release.<br>
- We probably should avoid having non-code issues in the<br>
graphics/krita repository. We have a repo for the funding website, one<br>
for documentation, and one for the regular website, and any of those<br>
would be fine. My problem with having them in the coding website is<br>
that we need to use that one the most, and non-coding issues tend to<br>
never close because of their ephemeral nature.<br>
<br>
---<br>
<br>
I'd like to invite you now to take a look at your own projects, and<br>
think about how you would use the issue system.<br>
<br>
- How will we handle really big projects, like platform support<br>
(wayland/macos/windows/android), or the tablet ui?<br>
- What about smaller projects like the panel cutter?<br>
- What about things like 'good first-time issues', 'xsimd porting' or<br>
even bugfixes?<br>
- What would you like to know about other projects? Issues are largely<br>
about communication, so what kind of things would make you feel like<br>
you understand other projects?<br>
- What would you find annoying? Can we have some kind of workaround for that?<br>
<br>
-- <br>
Wolthera<br>
</blockquote></div>