<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>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?</span></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div>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.</div><div><br></div><div>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). <br></div><div>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.<br></div><div>(Bugfix versions *might* sometimes make sense, but probably aren't always going to have enough planning involved to require a milestone. Probably overkill.)</div><div><br></div><div>Other things besides versions could make for good milestones too. <br></div><div>For example, a particular event (a fundraiser, a conference) or anything with any kind of <i>calendar deadline</i>.</div><div>(Like, or If we were working on a game project for example, "Announcement", "PublicBeta", "GamescomDemo", and "EarlyAccess" would also be good examples of milestones. </div><div>So I think it's not limited to only new versions, even if that's the most "obvious" application.)<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">The only thing I'm still unsure about is how<br>
I'd tackle the 3 different phases: Using labels means those labels<br>
will stay in the label dropdown long after the project is over. Using<br>
issues to represent the phases might be overdoing it? Not sure...</blockquote><div><br></div><div>Hmm... I don't know either.<br></div><div><br></div><div>If you mean phases of the project (like design, implementation, polish, review, etc.) then I <i>think</i> labels are probably the best fit for that.</div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>As in, we should consider issues and tasks as "belonging to" a given project.</div><div>While milestones and labels will be used across multiple projects, I think.</div><div><br></div><div>(For example, "GSoC" would be a good label, but a bad milestone. "GSoC-2025" would be a bad label, but a decent milestone. </div><div>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.)</div><div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 22, 2025 at 1:59 AM Dmitry Kazakov <<a href="mailto:dimula73@gmail.com" target="_blank">dimula73@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"><div dir="ltr"><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>1) It is difficult to track status of big projects.</div><div>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).</div><div>3) It is difficult to track what fixes/features reached which release</div><div>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)</div><div>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"</div><div><br></div><div>Looking at this list of "requirements", it doesn't look mandatory to have milestones for the releases, though I'm not very sure.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 22, 2025 at 10:49 AM Wolthera <<a href="mailto:griffinvalley@gmail.com" target="_blank">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">On Tue, Jul 22, 2025 at 10:45 AM Dmitry Kazakov <<a href="mailto:dimula73@gmail.com" target="_blank">dimula73@gmail.com</a>> wrote:<br>
><br>
> 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"?<br>
> --<br>
> Dmitry Kazakov<br>
<br>
I was hoping we'd first get an idea of how we want to use issues and<br>
milestones and the like, before we transition the issues. :) Might<br>
even be some don't get transitioned, I think we need to figure out<br>
what is comfortable first.<br>
<br>
Do you have a preference we move those issues into Krita main?<br>
<br>
-- <br>
Wolthera<br>
</blockquote></div><div><br clear="all"></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Dmitry Kazakov</div>
</blockquote></div>