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

[Emmet O'Neill]

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.

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.

On Tue, Jul 29, 2025 at 3:03 PM Emmet O'Neill <emmetoneill.pdx at gmail.com>
wrote:

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