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

[Christoph Läubrich <laeubi@xxxxxxxxxxxxxx>]

I think you falseley assume developers are addicted to manage their 
tickets... Why should I invest time to duplicate things that are already 
available?
Thats just a waste of time and no one will actually do that managing... 
but If you think you want to manage this and keep issues up to date 
(e.g. adding/removing labels as tickets change) I think no one will hold 
you back.

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

We should better invest time in fixing issues than managing their 
status, if you like to get some project managmaent, github offers 
projects for that:

https://docs.github.com/en/issues/trying-out-the-new-projects-experience/about-projects

but I hardly can imagine that most people are willing to invest the time 
even for that. TO be realistic, most tickets in Bugzilla lingering 
around in NEW, sometime one *might* assign it, but most of the time 
simply create a gerrit for it and if it merged mark it as resolved.

Am 29.04.22 um 08:51 schrieb Jens Lideström:
> > 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