<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 class="gmail-content" dir="auto">1. <a href="https://invent.kde.org/graphics/krita/-/boards" dir="auto" target="_blank" rel="noopener">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 class="gmail-content" 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 class="gmail-content" 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 class="gmail-content" 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 class="gmail-content" 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 class="gmail-content" dir="auto"><br></span></div><div><span class="gmail-content" dir="auto">While I'm at it:<br></span></div><div><span class="gmail-content" dir="auto"><br></span></div><div><span class="gmail-content" 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 class="gmail-content" 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 class="gmail-content" 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 class="gmail-content" dir="auto"><br></span></div><div><span class="gmail-content" dir="auto">That's all for now. Hopefully those changes are all fine. :)<br></span></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Jul 24, 2025 at 6:40 PM <<a href="mailto:halla@valdyas.org">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>