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

[halla at valdyas.org]

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