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

[Emmet O'Neill]

Based on this conversation, I've gone ahead and made some changes on
invent.kde:

1. https://invent.kde.org/graphics/krita/-/boards -- 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. :)
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.)
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.)
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.)
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.

While I'm at it:

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?
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?
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

That's all for now. Hopefully those changes are all fine. :)

On Thu, Jul 24, 2025 at 6:40 PM <halla at valdyas.org> wrote:

> I like that: those labels should be useful in making explicit what tends
> to be implicit.
>
> On 2025-07-25 00:34, Emmet O'Neill wrote:
> > I'd like to pitch 3 new issue-oriented gitlab labels to get us started
> > using the issue board:
> >
> >       * "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.)
> >
> >       * "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.)
> >
> >       * "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/20250729/fb472e54/attachment-0001.htm>