[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [platform-dev] Status field on GitHub issues
|
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