<div dir="ltr"><div>Re Q1: On second thought, I've just decided to go ahead and add a "Stage: Documentation" label and issue board column. I figured that it's best to make sure that documentation doesn't happen too early (before an issue is properly "refined" and in its final form) so that documentation doesn't end up needing to be redone if things change.</div><div><br></div><div>We can see how that goes for now and if it turns out to be not so helpful we can remove the label and column later.<br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, Jul 29, 2025 at 3:03 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"><div>Based on this conversation, I've gone ahead and made some changes on invent.kde:</div><div><br></div><div><span dir="auto">1. <a href="https://invent.kde.org/graphics/krita/-/boards" dir="auto" rel="noopener" target="_blank">https://invent.kde.org/graphics/krita/-/boards</a> -- The issue board has been set up, and I've created new labels that are meant to correspond to the various stages of issue development (planning, in-progress, and refinement). Issues should start on the left and move right until completion. :)<br></span></div><div><span dir="auto">2. I have moved existing issues from the open column into the corresponding columns. (Feel free to move your issues if you feel that they aren't in the right category.)</span></div><div><span dir="auto">3. I have updated some of the colors and descriptions of existing labels, in most cases pretty minorly. (You just might notice that some of the colors are a little bit different. I can't predict issues with colorblindness, but I tried to use logical color palettes for related things, so please chime in if any of the colors are confusing.)</span></div><div><span dir="auto">4. I removed the seemingly entirely unused "Tested" label. Both because I've never seen it used, and more importantly because things that have been tested should go into a more clear state (like "Needs Changes" or "Approved", for example.)</span></div><div><span dir="auto">5. I have not touched the milestones because we already have a bunch of perfect ones in place for various Krita versions. Please assign milestones to your tasks as you deem appropriate.<br></span></div><div><span dir="auto"><br></span></div><div><span dir="auto">While I'm at it:<br></span></div><div><span dir="auto"><br></span></div><div><span dir="auto">Q1: Should we include a "Stage: Documentation" column on the issue board? Or should we opt to keep things simple for now and just consider that to be part of the "Refinement" stage? <br></span></div><div><span dir="auto">Q2: Do we need a "Feature Request" label on Gitlab? I feel like the consensus is that we don't want to be getting feature requests or ideas here, and that it's best if those happen on Bugzilla or Krita-Artists. Maybe it should just say "Feature" instead, to indicate that an MR is providing a complete new feature instead of an "Enhancement" to an existing feature?<br></span></div><div><span dir="auto">Q3: Any objection to changing the color of the "Noteworthy" label away from that spooky-scary bloody danger red and to a nice first-place medal gold? :D<br></span></div><div><span dir="auto"><br></span></div><div><span dir="auto">That's all for now. Hopefully those changes are all fine. :)<br></span></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 24, 2025 at 6:40 PM <<a href="mailto:halla@valdyas.org" target="_blank">halla@valdyas.org</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">I like that: those labels should be useful in making explicit what tends <br>
to be implicit.<br>
<br>
On 2025-07-25 00:34, Emmet O'Neill wrote:<br>
> I'd like to pitch 3 new issue-oriented gitlab labels to get us started<br>
> using the issue board:<br>
> <br>
>       * "Planning" : This label should be applied to new issues or anything<br>
> where we are in the _planning phase_. Issues that are labelled as<br>
> "plans" are where we should discuss what problem we are trying to<br>
> solve, what our approach should be, what the UX should be, what the<br>
> "minimum viable feature" and threshold for completion is, and so on.<br>
> This is the time for mockups and design debates before much (if any)<br>
> code has been written. Most of the discussion will likely happen in<br>
> this phase of development. (After "Open", this would be the left-most<br>
> column on the issue board and where all planned features, large bug<br>
> fixes, and major changes should start.)<br>
> <br>
>       * "Work-In-Progress": This label should be applied to issues that<br>
> have previously been planned, and where the _implementation phase_ is<br>
> now underway. Issues labelled as "Work-In-Progress" may be associated<br>
> with a Merge Request, which should be linked in the issue. (This would<br>
> be a middle column on the issue board.)<br>
> <br>
>       * "Refinement": This label should be applied to issues where most of<br>
> the implementation work has been done, and so now all that remains is<br>
> the _polishing phase_. Issues in this stage of development may still<br>
> be associated with an open Merge Request, or in some cases the work<br>
> may have already been merged even if further refinement is planned.<br>
> (This would be the right-most column of the issue board.)<br>
> <br>
> As each of these labels should have their own column in the issue<br>
> board, the pipeline would end up being as such:<br>
> <br>
> Open (Default) -> Planning -> Work-In-Progress -> Refinement -> Closed<br>
> (Default)<br>
> <br>
> All issues should flow from left-to-right.<br>
> <br>
> So for planned features and other major changes, we create an issue<br>
> and move it into the planning column.<br>
> Once we have settled on a plan, identified the goals, considered the<br>
> UX, etc., we then move the feature into the work-in-progress column<br>
> and the work begins.<br>
> At some point in this process (up to the discretion and the style of<br>
> the person working on the project) the code will be pushed and a MR<br>
> will be opened.<br>
> Once the feature is ready for feedback, testing, review, a polish<br>
> pass, etc., the issue is moved into the refinement column.<br>
> <br>
> Finally, once the feature/change is merged, refined, and the goals set<br>
> in the planning stage have been adequately met, we can then close the<br>
> issue as the work is done.<br>
> <br>
> I hope this doesn't sound overly complicated, but I think having the<br>
> board arranged like this would help us (and the community) know<br>
> roughly where projects stand, how far along in development they are,<br>
> whether or not it is appropriate to give certain kinds of feedback,<br>
> etc.<br>
> <br>
> On Thu, Jul 24, 2025 at 7:10 AM Dmitry Kazakov <<a href="mailto:dimula73@gmail.com" target="_blank">dimula73@gmail.com</a>><br>
> wrote:<br>
> <br>
>> Just a short summary on tasks and features from the yesterday's<br>
>> discussion on IRC:<br>
>> <br>
>> 1) We create issues/tasks on GitLab/Phabricator only for features<br>
>> that has already been evaluated by the developers,<br>
>> were **planned** for implementation and the **work has been<br>
>> started**.<br>
>> 2) The issues are used only for delegating/sharing work to other<br>
>> people in the team<br>
>> (discussion and getting input/drafts is also "work")<br>
>> 3) "Feature requests indexing". We don't manage feature requests<br>
>> index, because we don't have enough human power to maintain that.<br>
>> Every feature request should be:<br>
>> <br>
>> 1) Evaluated with the two teams: developers/core-painters;<br>
>> 2) Estimated for size by developers;<br>
>> 3) Details discussed with the reposter;<br>
>> 4) Sorted into groups;<br>
>> That is a fulltime work. Check 524 [wishlist<br>
>> <br>
> items](<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=---" rel="noreferrer" 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>)<br>
>> on our bugzilla.<br>
>> It is almost impossible to maintain this list.<br>
>> 4) What we really need is an easily discovered list of junior-jobs<br>
>> for newcomers. The point is that "a junior job" is<br>
>> **completely different** from a feature request. It should be very<br>
>> clear and well-defined from both UIX and<br>
>> development point of view. To convert a feature request into a<br>
>> junior job a work of an experienced developer needed.<br>
>> Alternatively, a good mentor can be assigned to the newcomer, which<br>
>> will explain/convert a feature request<br>
>> for the newcomer. Currently, we use this alterantive approach, and<br>
>> every available mentor suggests features/tasks from his<br>
>> own bag (of interest).<br>
>> We could probably make some section on GitLab with "decided and<br>
>> accepted junior-job features", but this list should<br>
>> be strictly limited in size (e.g. 15), because converting a feature<br>
>> is a work of a developer.<br>
>> <br>
>> On Wed, Jul 23, 2025 at 11:11 PM Emmet O'Neill<br>
>> <<a href="mailto:emmetoneill.pdx@gmail.com" target="_blank">emmetoneill.pdx@gmail.com</a>> wrote:<br>
>> <br>
>> Question: can one issue/task belong to multiple milestones? E.g. "On<br>
>> Canvas Text Tool" and "Release Krita 5.3" at the same time? Will it<br>
>> look okay? Will there be any label-based conflicts?<br>
>> <br>
>> In this case I think the best organization would be to have "Text<br>
>> Tool" be a label (optionally, or something more general/reusable<br>
>> like "Tools"), with "Krita5.3" being the milestone that.<br>
>> <br>
>> Thinking of each milestone as a literal mile-marker along a road (or<br>
>> kilometer marker for all you non-North Americans :) ), it's<br>
>> something that we arrive at and then pass by.<br>
>> So versions are the most obvious example of that: eventually we will<br>
>> get to 5.3, and then it'll be behind us and we can start thinking<br>
>> about 5.4.<br>
>> <br>
>> I'd like to suggest that we always have a milestone for at least the<br>
>> *next major version* (Krita 6) and the *next minor version* (5.3).<br>
>> <br>
>> Doing this would help us plan a little further out in the future<br>
>> without mixing up mid-term and long-term goals that we have.<br>
>> <br>
>> (Bugfix versions *might* sometimes make sense, but probably aren't<br>
>> always going to have enough planning involved to require a<br>
>> milestone. Probably overkill.)<br>
>> <br>
>> Other things besides versions could make for good milestones too.<br>
>> <br>
>> For example, a particular event (a fundraiser, a conference) or<br>
>> anything with any kind of _calendar deadline_.<br>
>> (Like, or If we were working on a game project for example,<br>
>> "Announcement", "PublicBeta", "GamescomDemo", and "EarlyAccess"<br>
>> would also be good examples of milestones.<br>
>> So I think it's not limited to only new versions, even if that's the<br>
>> most "obvious" application.)<br>
>> <br>
>> 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.<br>
>> Using<br>
>> issues to represent the phases might be overdoing it? Not sure...<br>
>> <br>
>> Hmm... I don't know either.<br>
>> <br>
>> If you mean phases of the project (like design, implementation,<br>
>> polish, review, etc.) then I _think_ labels are probably the best<br>
>> fit for that.<br>
>> Mainly because if we use labels to represent the stages of<br>
>> development we can use board columns to see as things move from<br>
>> stage to stage.<br>
>> <br>
>> We should probably prefer labels that are as general as possible<br>
>> while still being clear, so that we can reuse them across projects,<br>
>> for the most part.<br>
>> <br>
>> As in, we should consider issues and tasks as "belonging to" a given<br>
>> project.<br>
>> While milestones and labels will be used across multiple projects, I<br>
>> think.<br>
>> <br>
>> (For example, "GSoC" would be a good label, but a bad milestone.<br>
>> "GSoC-2025" would be a bad label, but a decent milestone.<br>
>> Although... It still might be better to just use the release version<br>
>> that the project will eventually go into as the milestone in that<br>
>> case... It's hard to say.)<br>
>> <br>
>> On Tue, Jul 22, 2025 at 1:59 AM Dmitry Kazakov<br>
>> <<a href="mailto:dimula73@gmail.com" target="_blank">dimula73@gmail.com</a>> wrote:<br>
>> <br>
>> Well, no, I was not talking about your specific issues :) I was<br>
>> talking about an abstract case of a finished "milestone" and how it<br>
>> should be transitioned to the release milestone.<br>
>> <br>
>> The problem is that we have a problem of noting what came into<br>
>> release and what not. I personally had problems with keeping notes<br>
>> for the release announcement for the upcoming release. We need a<br>
>> place to keep them.<br>
>> <br>
>> Generally, I'm trying to approach the "issues problem" from a<br>
>> different side: from the side of the management problems we have.<br>
>> Here is the tentative problems we have that could be addressed with<br>
>> the help of GitLab issues:<br>
>> <br>
>> 1) It is difficult to track status of big projects.<br>
>> 2) It is difficult to discuss some individual issues/bugs/problems<br>
>> we have (we have to use IRC for that and it breaks over timezone<br>
>> differences).<br>
>> 3) It is difficult to track what fixes/features reached which<br>
>> release<br>
>> 4) It is difficult to plan what issues/features should have a<br>
>> priority to reach some specific release (well, we currently don't<br>
>> really have enough manpower to plan so deep, but it used to be an<br>
>> issue before)<br>
>> 5) It is difficult to leave notes for the release notes for the<br>
>> upcoming release, e.g. " AppImage runtime has changed, use this<br>
>> manual if you have any issues"<br>
>> <br>
>> Looking at this list of "requirements", it doesn't look mandatory to<br>
>> have milestones for the releases, though I'm not very sure.<br>
>> <br>
>> On Tue, Jul 22, 2025 at 10:49 AM Wolthera<br>
>> <<a href="mailto:griffinvalley@gmail.com" target="_blank">griffinvalley@gmail.com</a>> wrote:<br>
>> On Tue, Jul 22, 2025 at 10:45 AM Dmitry Kazakov<br>
>> <<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<br>
>> into "Release 5.3.0"? Only the "root" issue should belong to<br>
>> "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>
>> <br>
>> --<br>
>> Dmitry Kazakov<br>
> <br>
> --<br>
> Dmitry Kazakov<br>
</blockquote></div>
</blockquote></div>