We can now use gitlab issues, how are we going to use them?

[Emmet O'Neill]

I'd like to pitch 3 new issue-oriented gitlab labels to get us started
using the issue board:

   1. "*Planning*" : This label should be applied to new issues or anything
   where we are in the *planning phase*. 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.)
   2. "*Work-In-Progress*": This label should be applied to issues that
   have previously been planned, and where the *implementation phase* 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.)
   3. "*Refinement*": This label should be applied to issues where most of
   the implementation work has been done, and so now all that remains
is the *polishing
   phase*. 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.)

As each of these labels should have their own column in the issue board,
the pipeline would end up being as such:

*Open (Default) -> Planning -> Work-In-Progress -> Refinement -> Closed
(Default)*

All issues should flow from left-to-right.

So for planned features and other major changes, we create an issue and
move it into the planning column.
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.
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.
Once the feature is ready for feedback, testing, review, a polish pass,
etc., the issue is moved into the refinement column.
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.

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.

On Thu, Jul 24, 2025 at 7:10 AM Dmitry Kazakov <dimula73 at gmail.com> wrote:

> Just a short summary on tasks and features from the yesterday's discussion
> on IRC:
>
> 1) We create issues/tasks on GitLab/Phabricator only for features that has
> already been evaluated by the developers,
> were **planned** for implementation and the **work has been started**.
>
> 2) The issues are used only for delegating/sharing work to other people in
> the team
> (discussion and getting input/drafts is also "work")
>
> 3) "Feature requests indexing". We don't manage feature requests index,
> because we don't have enough human power to maintain that.
> Every feature request should be:
> 1) Evaluated with the two teams: developers/core-painters;
> 2) Estimated for size by developers;
> 3) Details discussed with the reposter;
> 4) Sorted into groups;
>
> That is a fulltime work. Check 524 [wishlist items](
> 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=---
> ) on our bugzilla.
> It is almost impossible to maintain this list.
>
> 4) What we really need is an easily discovered list of junior-jobs for
> newcomers. The point is that "a junior job" is
> **completely different** from a feature request. It should be very clear
> and well-defined from both UIX and
> development point of view. To convert a feature request into a junior job
> a work of an experienced developer needed.
>
> Alternatively, a good mentor can be assigned to the newcomer, which will
> explain/convert a feature request
> for the newcomer. Currently, we use this alterantive approach, and every
> available mentor suggests features/tasks from his
> own bag (of interest).
>
> We could probably make some section on GitLab with "decided and accepted
> junior-job features", but this list should
> be strictly limited in size (e.g. 15), because converting a feature is a
> work of a developer.
>
>
> On Wed, Jul 23, 2025 at 11:11 PM Emmet O'Neill <emmetoneill.pdx at gmail.com>
> wrote:
>
>> 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?
>>
>>
>> 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.
>>
>> 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.
>> 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.
>>
>> 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).
>> 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.
>> (Bugfix versions *might* sometimes make sense, but probably aren't always
>> going to have enough planning involved to require a milestone. Probably
>> overkill.)
>>
>> Other things besides versions could make for good milestones too.
>> For example, a particular event (a fundraiser, a conference) or anything
>> with any kind of *calendar deadline*.
>> (Like, or If we were working on a game project for example,
>> "Announcement", "PublicBeta", "GamescomDemo", and "EarlyAccess" would also
>> be good examples of milestones.
>> So I think it's not limited to only new versions, even if that's the most
>> "obvious" application.)
>>
>> The only thing I'm still unsure about is how
>>> I'd tackle the 3 different phases: Using labels means those labels
>>> will stay in the label dropdown long after the project is over. Using
>>> issues to represent the phases might be overdoing it? Not sure...
>>
>>
>> Hmm... I don't know either.
>>
>> If you mean phases of the project (like design, implementation, polish,
>> review, etc.) then I *think* labels are probably the best fit for that.
>> 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.
>>
>> 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.
>>
>> As in, we should consider issues and tasks as "belonging to" a given
>> project.
>> While milestones and labels will be used across multiple projects, I
>> think.
>>
>> (For example, "GSoC" would be a good label, but a bad milestone.
>> "GSoC-2025" would be a bad label, but a decent milestone.
>> 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.)
>>
>>
>> On Tue, Jul 22, 2025 at 1:59 AM Dmitry Kazakov <dimula73 at gmail.com>
>> wrote:
>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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:
>>>
>>> 1) It is difficult to track status of big projects.
>>> 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).
>>> 3) It is difficult to track what fixes/features reached which release
>>> 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)
>>> 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"
>>>
>>> Looking at this list of "requirements", it doesn't look mandatory to
>>> have milestones for the releases, though I'm not very sure.
>>>
>>> On Tue, Jul 22, 2025 at 10:49 AM Wolthera <griffinvalley at gmail.com>
>>> wrote:
>>>
>>>> On Tue, Jul 22, 2025 at 10:45 AM Dmitry Kazakov <dimula73 at gmail.com>
>>>> wrote:
>>>> >
>>>> > 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"?
>>>> > --
>>>> > Dmitry Kazakov
>>>>
>>>> I was hoping we'd first get an idea of how we want to use issues and
>>>> milestones and the like, before we transition the issues. :) Might
>>>> even be some don't get transitioned, I think we need to figure out
>>>> what is comfortable first.
>>>>
>>>> Do you have a preference we move those issues into Krita main?
>>>>
>>>> --
>>>> Wolthera
>>>>
>>>
>>>
>>> --
>>> Dmitry Kazakov
>>>
>>
>
> --
> Dmitry Kazakov
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20250724/3f2dcff6/attachment-0001.htm>