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

[Emmet O'Neill]

>
> Question: can one issue/task belong to multiple milestones? E.g. "On
> Canvas Text Tool" and "Release Krita 5.3" at the same time? Will it look
> okay? Will there be any label-based conflicts?


In this case I think the best organization would be to have "Text Tool" be
a label (optionally, or something more general/reusable like "Tools"), with
"Krita5.3" being the milestone that.

Thinking of each milestone as a literal mile-marker along a road (or
kilometer marker for all you non-North Americans :) ), it's something that
we arrive at and then pass by.
So versions are the most obvious example of that: eventually we will get to
5.3, and then it'll be behind us and we can start thinking about 5.4.

I'd like to suggest that we always have a milestone for at least the *next
major version* (Krita 6) and the *next minor version* (5.3).
Doing this would help us plan a little further out in the future without
mixing up mid-term and long-term goals that we have.
(Bugfix versions *might* sometimes make sense, but probably aren't always
going to have enough planning involved to require a milestone. Probably
overkill.)

Other things besides versions could make for good milestones too.
For example, a particular event (a fundraiser, a conference) or anything
with any kind of *calendar deadline*.
(Like, or If we were working on a game project for example, "Announcement",
"PublicBeta", "GamescomDemo", and "EarlyAccess" would also be good examples
of milestones.
So I think it's not limited to only new versions, even if that's the most
"obvious" application.)

The only thing I'm still unsure about is how
> I'd tackle the 3 different phases: Using labels means those labels
> will stay in the label dropdown long after the project is over. Using
> issues to represent the phases might be overdoing it? Not sure...


Hmm... I don't know either.

If you mean phases of the project (like design, implementation, polish,
review, etc.) then I *think* labels are probably the best fit for that.
Mainly because if we use labels to represent the stages of development we
can use board columns to see as things move from stage to stage.

We should probably prefer labels that are as general as possible while
still being clear, so that we can reuse them across projects, for the most
part.

As in, we should consider issues and tasks as "belonging to" a given
project.
While milestones and labels will be used across multiple projects, I think.

(For example, "GSoC" would be a good label, but a bad milestone.
"GSoC-2025" would be a bad label, but a decent milestone.
Although... It still might be better to just use the release version that
the project will eventually go into as the milestone in that case... It's
hard to say.)


On Tue, Jul 22, 2025 at 1:59 AM Dmitry Kazakov <dimula73 at gmail.com> wrote:

> Well, no, I was not talking about your specific issues :) I was talking
> about an abstract case of a finished "milestone" and how it should be
> transitioned to the release milestone.
>
> The problem is that we have a problem of noting what came into release and
> what not. I personally had problems with keeping notes for the release
> announcement for the upcoming release. We need a place to keep them.
>
> Generally, I'm trying to approach the "issues problem" from a different
> side: from the side of the management problems we have. Here is the
> tentative problems we have that could be addressed with the help of GitLab
> issues:
>
> 1) It is difficult to track status of big projects.
> 2) It is difficult to discuss some individual issues/bugs/problems we have
> (we have to use IRC for that and it breaks over timezone differences).
> 3) It is difficult to track what fixes/features reached which release
> 4) It is difficult to plan what issues/features should have a priority to
> reach some specific release (well, we currently don't really have enough
> manpower to plan so deep, but it used to be an issue before)
> 5) It is difficult to leave notes for the release notes for the upcoming
> release, e.g. " AppImage runtime has changed, use this manual if you have
> any issues"
>
> Looking at this list of "requirements", it doesn't look mandatory to have
> milestones for the releases, though I'm not very sure.
>
> On Tue, Jul 22, 2025 at 10:49 AM Wolthera <griffinvalley at gmail.com> wrote:
>
>> On Tue, Jul 22, 2025 at 10:45 AM Dmitry Kazakov <dimula73 at gmail.com>
>> wrote:
>> >
>> > Then how should we transition your "Text Tool" milestoned tasks into
>> "Release 5.3.0"? Only the "root" issue should belong to "Release 5.3.0"?
>> > --
>> > Dmitry Kazakov
>>
>> I was hoping we'd first get an idea of how we want to use issues and
>> milestones and the like, before we transition the issues. :) Might
>> even be some don't get transitioned, I think we need to figure out
>> what is comfortable first.
>>
>> Do you have a preference we move those issues into Krita main?
>>
>> --
>> Wolthera
>>
>
>
> --
> Dmitry Kazakov
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20250723/213d6082/attachment.htm>