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

Thu Jul 24 15:09:45 BST 2025

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/a02773ad/attachment.htm>