<div dir="ltr"><div>I'd like to pitch 3 new issue-oriented gitlab labels to get us started using the issue board:</div><div><ol><li>"<b>Planning</b>" : This label should be applied to new issues or anything where we are in the <i>planning phase</i>. Issues that are labelled as "plans" are where we should discuss what problem we are trying to solve, what our approach should be, what the UX should be, what the "minimum viable feature" and threshold for completion is, and so on. This is the time for mockups and design debates before much (if any) code has been written. Most of the discussion will likely happen in this phase of development. (After "Open", this would be the left-most column on the issue board and where all planned features, large bug fixes, and major changes should start.) <br></li><li>"<b>Work-In-Progress</b>": This label should be applied to issues that have previously been planned, and where the <i>implementation phase</i> is now underway. Issues labelled as "Work-In-Progress" may be associated with a Merge Request, which should be linked in the issue. (This would be a middle column on the issue board.)<br></li><li>"<b>Refinement</b>": This label should be applied to issues where most of the implementation work has been done, and so now all that remains is the <i>polishing phase</i>. Issues in this stage of development may still be associated with an open Merge Request, or in some cases the work may have already been merged even if further refinement is planned. (This would be the right-most column of the issue board.)<br></li></ol><div>As each of these labels should have their own column in the issue board, the pipeline would end up being as such:</div><div><br></div><div><b>Open (Default) -> Planning -> Work-In-Progress -> Refinement -> Closed (Default)</b></div><div><b><br></b></div><div>All issues should flow from left-to-right.<br></div><div><br></div><div>So for planned features and other major changes, we create an issue and move it into the planning column.</div><div>Once we have settled on a plan, identified the goals, considered the UX, etc., we then move the feature into the work-in-progress column and the work begins.</div><div>At some point in this process (up to the discretion and the style of the person working on the project) the code will be pushed and a MR will be opened.</div><div>Once the feature is ready for feedback, testing, review, a polish pass, etc., the issue is moved into the refinement column. <br></div><div>Finally, once the feature/change is merged, refined, and the goals set in the planning stage have been adequately met, we can then close the issue as the work is done.</div><div><br></div><div>I hope this doesn't sound overly complicated, but I think having the board arranged like this would help us (and the community) know roughly where projects stand, how far along in development they are, whether or not it is appropriate to give certain kinds of feedback, etc.</div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Jul 24, 2025 at 7:10 AM Dmitry Kazakov <<a href="mailto:dimula73@gmail.com">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>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-wrap"><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=---" target="_blank">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"><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" target="_blank">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>
</blockquote></div>