Re: [platform-dev] Status field on GitHub issues

[Lars Vogel <lars.vogel@xxxxxxxxxxx>]

I don't mind having additional labels available but I'm against making
their usage mandatory. We should not try to replicate the way of
working (or burden depending on the point of view) of Bugzilla to
Github.

On Fri, Apr 29, 2022 at 8:51 AM Jens Lideström <jens@xxxxxxxxxxxx> wrote:
>
> > new -> is:open no:assignee
> > ongoing -> is:open assignee:*
> > blocked -> anyone really filtering for that?
> > duplicate -> [1]
> > worksforme -> simply close it with a comment
> > invalid  -> simply close it with a comment
> > fixed  -> [2] then is:closed linked:pr
>
> This is a perfect illustration of why I think it is a good idea to use
> labels for the status of issues!
>
> In the above system you have to use information from multiple places,
> including the comments, plus some inference to deduce the status of an
> issue. I also strongly suspect that in practice many cases will not be
> so clear cut and it will be hard to make this deduction.
>
> The status in Bugzilla is EXPLICIT, IMMEDIATELY VISIBLE and has
> STANDARDIZED VALUES. That's what makes it more useful and convenient
> than the system above.
>
> I still suggest adding those labels on the organisation level. I think
> that will make all our lives a little easier. Projects that don't want
> to use them can disable the default labels.
>
> > blocked -> anyone really filtering for that?
>
> The status is not only about filtering. It is also about being able to
> immediately see the status of an issue when you open it up.
>
> BR,
> Jens Lideström
>
>
> 2022-04-29 06:15 skrev Christoph Läubrich:
> >> When browsing issues on GitHub I have often been confused about their
> >> status.
> >
> > new -> is:open no:assignee
> > ongoing -> is:open assignee:*
> > blocked -> anyone really filtering for that?
> > duplicate -> [1]
> > worksforme -> simply close it with a comment
> > invalid  -> simply close it with a comment
> > fixed  -> [2] then is:closed linked:pr
> >
> > There is much more to discover:
> >
> > https://docs.github.com/en/search-github/searching-on-github/searching-issues-and-pull-requests
> >
> > [1]
> > https://docs.github.com/en/issues/tracking-your-work-with-issues/marking-issues-or-pull-requests-as-a-duplicate
> > [2] https://github.blog/2013-01-22-closing-issues-via-commit-messages/
> >
> >
> > Am 28.04.22 um 21:53 schrieb Jens Lideström:
> >> One convenient detail in Bugzilla is that there is a "Status" field on
> >> every issue. The status is explicit, has standardized values and is
> >> immediately visible.
> >>
> >> When browsing issues on GitHub I have often been confused about their
> >> status.
> >>
> >> I suggest this: All Eclipse projects on GitHub should have labels for
> >> the most important status values that exist in Bugzilla.
> >>
> >> Maybe the following status values should exist:
> >>
> >> new
> >> ongoing
> >> blocked
> >> duplicate
> >> worksforme
> >> invalid
> >> fixed
> >>
> >> It would be preferable if one of the status labels would be mandatory
> >> for a issue to be closed, but I don't know if GitHub has functionality
> >> for that.
> >>
> >> Bugzilla status values:
> >> https://bugs.eclipse.org/bugs/page.cgi?id=fields.html#bug_status
> >>
> >> Labels for an organisation in GitHub:
> >> https://docs.github.com/en/organizations/managing-organization-settings/managing-default-labels-for-repositories-in-your-organization
> >> BR,
> >> Jens Lideström
> >>
> _______________________________________________
> platform-dev mailing list
> platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev



-- 
Eclipse Platform project co-lead
CEO vogella GmbH

Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Fax (040) 5247 6322, Email: lars.vogel@xxxxxxxxxxx, Web: http://www.vogella.com