<div dir="ltr"><div>Just a short summary on tasks and features from the yesterday's discussion on IRC:</div><div><br></div><div><div style="color:rgb(46,46,46);background-color:rgb(255,255,255);font-family:"GitLab Mono",JetBrains Mono,Menlo,DejaVu Sans Mono,Liberation Mono,Consolas,Ubuntu Mono,Courier New,andale mono,lucida console,monospace,"Droid Sans Mono","monospace",monospace,"Droid Sans Fallback";font-weight:normal;font-size:14px;line-height:19px;white-space:pre"><div><span style="color:rgb(46,46,46)">1) We create issues/tasks on GitLab/Phabricator only for features that has already been evaluated by the developers, </span></div><div><span style="color:rgb(46,46,46)"> were **planned** for implementation and the **work has been started**.</span></div><br><div><span style="color:rgb(46,46,46)">2) The issues are used only for delegating/sharing work to other people in the team </span></div><div><span style="color:rgb(46,46,46)"> (discussion and getting input/drafts is also "work")</span></div><br><div><span style="color:rgb(46,46,46)">3) "Feature requests indexing". We don't manage feature requests index, because we don't have enough human power to maintain that. </span></div><div><span style="color:rgb(46,46,46)"> Every feature request should be:</span></div><div><span style="color:rgb(46,46,46)"> </span></div><div><span style="color:rgb(46,46,46)"> 1) Evaluated with the two teams: developers/core-painters;</span></div><div><span style="color:rgb(46,46,46)"> 2) Estimated for size by developers; </span></div><div><span style="color:rgb(46,46,46)"> 3) Details discussed with the reposter; </span></div><div><span style="color:rgb(46,46,46)"> 4) Sorted into groups;</span></div><br><div><span style="color:rgb(46,46,46)"> That is a fulltime work. Check 524 </span><span style="color:rgb(170,0,0)">[</span><span style="color:rgb(46,46,46)">wishlist items</span><span style="color:rgb(170,0,0)">](<a href="https://bugs.kde.org/buglist.cgi?bug_severity=wishlist&bug_severity=task&bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&columnlist=product%2Cbug_severity%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Cchangeddate&limit=0&list_id=3208770&order=bug_id&product=krita&query_format=advanced&resolution=---">https://bugs.kde.org/buglist.cgi?bug_severity=wishlist&bug_severity=task&bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&columnlist=product%2Cbug_severity%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Cchangeddate&limit=0&list_id=3208770&order=bug_id&product=krita&query_format=advanced&resolution=---</a>)</span><span style="color:rgb(46,46,46)"> on our bugzilla.</span></div><div><span style="color:rgb(46,46,46)"> It is almost impossible to maintain this list.</span></div><br><div><span style="color:rgb(46,46,46)">4) What we really need is an easily discovered list of junior-jobs for newcomers. The point is that "a junior job" is </span></div><div><span style="color:rgb(46,46,46)"> **completely different** from a feature request. It should be very clear and well-defined from both UIX and </span></div><div><span style="color:rgb(46,46,46)"> development point of view. To convert a feature request into a junior job a work of an experienced developer needed.</span></div><br><div><span style="color:rgb(46,46,46)"> Alternatively, a good mentor can be assigned to the newcomer, which will explain/convert a feature request</span></div><div><span style="color:rgb(46,46,46)"> for the newcomer. Currently, we use this alterantive approach, and every available mentor suggests features/tasks from his</span></div><div><span style="color:rgb(46,46,46)"> own bag (of interest).</span></div><br><div><span style="color:rgb(46,46,46)"> We could probably make some section on GitLab with "decided and accepted junior-job features", but this list should</span></div><div><span style="color:rgb(46,46,46)"> be strictly limited in size (e.g. 15), because converting a feature is a work of a developer.</span></div></div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Jul 23, 2025 at 11:11 PM Emmet O'Neill <<a href="mailto:emmetoneill.pdx@gmail.com">emmetoneill.pdx@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"><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>
</blockquote></div><div><br clear="all"></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Dmitry Kazakov</div>