You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@polaris.apache.org by Michael Collado <co...@gmail.com> on 2025/01/16 21:56:04 UTC
Use of the "bug" label in Github issues
Hey folks
There are over 40 issues with the "bug" label in github right now, many of
which are not actually bugs, but seem to me like personal preferences or
possible improvements. A lot of these issues seem like reasonable or good
changes to me, but I think we should reserve the "bug" label for things
that are actual bugs. Can we remove the bug label from issues that aren't
actually broken?
Mike
Re: Use of the "bug" label in Github issues
Posted by Yufei Gu <fl...@gmail.com>.
+1. Always good to put more thought into existing issues.
Yufei
On Thu, Jan 16, 2025 at 1:56 PM Michael Collado <co...@gmail.com>
wrote:
> Hey folks
>
> There are over 40 issues with the "bug" label in github right now, many of
> which are not actually bugs, but seem to me like personal preferences or
> possible improvements. A lot of these issues seem like reasonable or good
> changes to me, but I think we should reserve the "bug" label for things
> that are actual bugs. Can we remove the bug label from issues that aren't
> actually broken?
>
> Mike
>
Re: Use of the "bug" label in Github issues
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Good point, it makes sense to me.
Regards
JB
Le ven. 17 janv. 2025 à 06:51, Eric Maynard <er...@gmail.com> a
écrit :
> I would also suggest that “bug” can be used when functionality does not
> match the docs, the spec, etc.
>
> On Thu, Jan 16, 2025 at 9:00 PM Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
>
> > Hi Mike
> >
> > I agree, the bug label should mean: this is something breaking
> > *compared* to a previous commit (as we don't have release yet :)). The
> > GH Issues considering a "bug" not related to a previous commit is an
> > "improvement" to me: it's not a bug introduced on top of a previous
> > commit but more an "general concern/bug" we have in mind, so an
> > improvement on the existing.
> >
> > To sum-up:
> > - we should use "bug" for issue introduced by a commit after another
> > commit (history)
> > - we should use "improvement" for issue/improvement we want to
> > implement (it could be considered as a bug from a personal standpoint
> > but not related to project history)
> > - we should use "new feature" for new functionality we want to
> > implement in the project
> > - we should use "proposal" for design/MVP
> >
> > Regards
> > JB
> >
> > On Thu, Jan 16, 2025 at 10:56 PM Michael Collado <collado.mike@gmail.com
> >
> > wrote:
> > >
> > > Hey folks
> > >
> > > There are over 40 issues with the "bug" label in github right now, many
> > of
> > > which are not actually bugs, but seem to me like personal preferences
> or
> > > possible improvements. A lot of these issues seem like reasonable or
> good
> > > changes to me, but I think we should reserve the "bug" label for things
> > > that are actual bugs. Can we remove the bug label from issues that
> aren't
> > > actually broken?
> > >
> > > Mike
> >
>
Re: Use of the "bug" label in Github issues
Posted by Eric Maynard <er...@gmail.com>.
I would also suggest that “bug” can be used when functionality does not
match the docs, the spec, etc.
On Thu, Jan 16, 2025 at 9:00 PM Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:
> Hi Mike
>
> I agree, the bug label should mean: this is something breaking
> *compared* to a previous commit (as we don't have release yet :)). The
> GH Issues considering a "bug" not related to a previous commit is an
> "improvement" to me: it's not a bug introduced on top of a previous
> commit but more an "general concern/bug" we have in mind, so an
> improvement on the existing.
>
> To sum-up:
> - we should use "bug" for issue introduced by a commit after another
> commit (history)
> - we should use "improvement" for issue/improvement we want to
> implement (it could be considered as a bug from a personal standpoint
> but not related to project history)
> - we should use "new feature" for new functionality we want to
> implement in the project
> - we should use "proposal" for design/MVP
>
> Regards
> JB
>
> On Thu, Jan 16, 2025 at 10:56 PM Michael Collado <co...@gmail.com>
> wrote:
> >
> > Hey folks
> >
> > There are over 40 issues with the "bug" label in github right now, many
> of
> > which are not actually bugs, but seem to me like personal preferences or
> > possible improvements. A lot of these issues seem like reasonable or good
> > changes to me, but I think we should reserve the "bug" label for things
> > that are actual bugs. Can we remove the bug label from issues that aren't
> > actually broken?
> >
> > Mike
>
Re: Use of the "bug" label in Github issues
Posted by Eric Maynard <er...@gmail.com>.
I agree that the templates can improve -- but we can and should remove the
bug label from things that aren't actually broken even after an issue is
filed.
On Fri, Jan 17, 2025 at 3:55 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:
> Hi Alex
>
> Fully agree: I think we should change our GH templates here and at least
> give “free” fields to the users.
>
> I would be more than happy to propose a PR to update the templates and
> “relax” the fields for the user.
>
> Regards
> JB
>
> Le ven. 17 janv. 2025 à 12:34, Alex Dutra <al...@dremio.com.invalid>
> a
> écrit :
>
> > Hi,
> >
> > If there are issues incorrectly labeled as bugs, that's maybe also
> because
> > we don't give many choices to users; when opening an issue, our templates
> > are very opinionated and only offer 3 options: "Bug report", "Feature
> > request", and "Report a security vulnerability" (with too many fields to
> > fill in imho – but that's a different topic). There is no clear way to
> log
> > things like: tasks, chores, performance issues, proposals for
> configuration
> > changes, questions, doubts, documentation changes, suggestions for
> > refactorings, additions or modifications in CI tests, etc. So I guess
> that
> > most users just go for "Bug Report".
> >
> > Alex
> >
> > On Fri, Jan 17, 2025 at 8:34 AM Michael Collado <co...@gmail.com>
> > wrote:
> >
> > > I agree that tackling real issues in a timely manner is super
> important.
> > > That’s why I think it’s important to be judicious in labeling issues as
> > > “bugs”. When the queue becomes too noisy, people learn to ignore it and
> > > important things get missed. When given the choice between too much
> noise
> > > and too little signal, I tend to err on the side of eliminating the
> noise
> > > so that at least we develop the habit of looking at whatever does come
> > > through.
> > >
> > > I’m glad to see all the issues being filed and all the accompanying
> > > activity. I just think we should be clear on how we label things so
> > > everyone knows how to prioritize.
> > >
> > > Mike
> > >
> > > On Thu, Jan 16, 2025 at 11:26 PM Eric Maynard <
> eric.w.maynard@gmail.com>
> > > wrote:
> > >
> > > > No, actually I don't think we need to argue much. We should try to
> > label
> > > > things correctly and the difference between what is a bug and what is
> > > not a
> > > > bug is typically evident.
> > > >
> > > > This is a bug, <https://github.com/apache/polaris/issues/813> and
> this
> > > is
> > > > not <https://github.com/apache/polaris/issues/773>. Both of these
> are
> > > > legitimate issues, but how they are labelled is important.
> > > >
> > > > On Thu, Jan 16, 2025 at 11:20 PM Robert Stupp <sn...@snazy.de>
> wrote:
> > > >
> > > > > We can argue a long time about labels and their usage and about the
> > > > > formal definition of those.
> > > > >
> > > > > What I think really matters is that the issues, especially real
> bugs,
> > > > > with security issues being the absolute #1 priority, are tackled
> in a
> > > > > timely manner.
> > > > >
> > > > > On 17.01.25 06:00, Jean-Baptiste Onofré wrote:
> > > > > > Hi Mike
> > > > > >
> > > > > > I agree, the bug label should mean: this is something breaking
> > > > > > *compared* to a previous commit (as we don't have release yet
> :)).
> > > The
> > > > > > GH Issues considering a "bug" not related to a previous commit is
> > an
> > > > > > "improvement" to me: it's not a bug introduced on top of a
> previous
> > > > > > commit but more an "general concern/bug" we have in mind, so an
> > > > > > improvement on the existing.
> > > > > >
> > > > > > To sum-up:
> > > > > > - we should use "bug" for issue introduced by a commit after
> > another
> > > > > > commit (history)
> > > > > > - we should use "improvement" for issue/improvement we want to
> > > > > > implement (it could be considered as a bug from a personal
> > standpoint
> > > > > > but not related to project history)
> > > > > > - we should use "new feature" for new functionality we want to
> > > > > > implement in the project
> > > > > > - we should use "proposal" for design/MVP
> > > > > >
> > > > > > Regards
> > > > > > JB
> > > > > >
> > > > > > On Thu, Jan 16, 2025 at 10:56 PM Michael Collado <
> > > > collado.mike@gmail.com>
> > > > > wrote:
> > > > > >> Hey folks
> > > > > >>
> > > > > >> There are over 40 issues with the "bug" label in github right
> now,
> > > > many
> > > > > of
> > > > > >> which are not actually bugs, but seem to me like personal
> > > preferences
> > > > or
> > > > > >> possible improvements. A lot of these issues seem like
> reasonable
> > or
> > > > > good
> > > > > >> changes to me, but I think we should reserve the "bug" label for
> > > > things
> > > > > >> that are actual bugs. Can we remove the bug label from issues
> that
> > > > > aren't
> > > > > >> actually broken?
> > > > > >>
> > > > > >> Mike
> > > > >
> > > > > --
> > > > > Robert Stupp
> > > > > @snazy
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Use of the "bug" label in Github issues
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Alex
Fully agree: I think we should change our GH templates here and at least
give “free” fields to the users.
I would be more than happy to propose a PR to update the templates and
“relax” the fields for the user.
Regards
JB
Le ven. 17 janv. 2025 à 12:34, Alex Dutra <al...@dremio.com.invalid> a
écrit :
> Hi,
>
> If there are issues incorrectly labeled as bugs, that's maybe also because
> we don't give many choices to users; when opening an issue, our templates
> are very opinionated and only offer 3 options: "Bug report", "Feature
> request", and "Report a security vulnerability" (with too many fields to
> fill in imho – but that's a different topic). There is no clear way to log
> things like: tasks, chores, performance issues, proposals for configuration
> changes, questions, doubts, documentation changes, suggestions for
> refactorings, additions or modifications in CI tests, etc. So I guess that
> most users just go for "Bug Report".
>
> Alex
>
> On Fri, Jan 17, 2025 at 8:34 AM Michael Collado <co...@gmail.com>
> wrote:
>
> > I agree that tackling real issues in a timely manner is super important.
> > That’s why I think it’s important to be judicious in labeling issues as
> > “bugs”. When the queue becomes too noisy, people learn to ignore it and
> > important things get missed. When given the choice between too much noise
> > and too little signal, I tend to err on the side of eliminating the noise
> > so that at least we develop the habit of looking at whatever does come
> > through.
> >
> > I’m glad to see all the issues being filed and all the accompanying
> > activity. I just think we should be clear on how we label things so
> > everyone knows how to prioritize.
> >
> > Mike
> >
> > On Thu, Jan 16, 2025 at 11:26 PM Eric Maynard <er...@gmail.com>
> > wrote:
> >
> > > No, actually I don't think we need to argue much. We should try to
> label
> > > things correctly and the difference between what is a bug and what is
> > not a
> > > bug is typically evident.
> > >
> > > This is a bug, <https://github.com/apache/polaris/issues/813> and this
> > is
> > > not <https://github.com/apache/polaris/issues/773>. Both of these are
> > > legitimate issues, but how they are labelled is important.
> > >
> > > On Thu, Jan 16, 2025 at 11:20 PM Robert Stupp <sn...@snazy.de> wrote:
> > >
> > > > We can argue a long time about labels and their usage and about the
> > > > formal definition of those.
> > > >
> > > > What I think really matters is that the issues, especially real bugs,
> > > > with security issues being the absolute #1 priority, are tackled in a
> > > > timely manner.
> > > >
> > > > On 17.01.25 06:00, Jean-Baptiste Onofré wrote:
> > > > > Hi Mike
> > > > >
> > > > > I agree, the bug label should mean: this is something breaking
> > > > > *compared* to a previous commit (as we don't have release yet :)).
> > The
> > > > > GH Issues considering a "bug" not related to a previous commit is
> an
> > > > > "improvement" to me: it's not a bug introduced on top of a previous
> > > > > commit but more an "general concern/bug" we have in mind, so an
> > > > > improvement on the existing.
> > > > >
> > > > > To sum-up:
> > > > > - we should use "bug" for issue introduced by a commit after
> another
> > > > > commit (history)
> > > > > - we should use "improvement" for issue/improvement we want to
> > > > > implement (it could be considered as a bug from a personal
> standpoint
> > > > > but not related to project history)
> > > > > - we should use "new feature" for new functionality we want to
> > > > > implement in the project
> > > > > - we should use "proposal" for design/MVP
> > > > >
> > > > > Regards
> > > > > JB
> > > > >
> > > > > On Thu, Jan 16, 2025 at 10:56 PM Michael Collado <
> > > collado.mike@gmail.com>
> > > > wrote:
> > > > >> Hey folks
> > > > >>
> > > > >> There are over 40 issues with the "bug" label in github right now,
> > > many
> > > > of
> > > > >> which are not actually bugs, but seem to me like personal
> > preferences
> > > or
> > > > >> possible improvements. A lot of these issues seem like reasonable
> or
> > > > good
> > > > >> changes to me, but I think we should reserve the "bug" label for
> > > things
> > > > >> that are actual bugs. Can we remove the bug label from issues that
> > > > aren't
> > > > >> actually broken?
> > > > >>
> > > > >> Mike
> > > >
> > > > --
> > > > Robert Stupp
> > > > @snazy
> > > >
> > > >
> > >
> >
>
Re: Use of the "bug" label in Github issues
Posted by Alex Dutra <al...@dremio.com.INVALID>.
Hi,
If there are issues incorrectly labeled as bugs, that's maybe also because
we don't give many choices to users; when opening an issue, our templates
are very opinionated and only offer 3 options: "Bug report", "Feature
request", and "Report a security vulnerability" (with too many fields to
fill in imho – but that's a different topic). There is no clear way to log
things like: tasks, chores, performance issues, proposals for configuration
changes, questions, doubts, documentation changes, suggestions for
refactorings, additions or modifications in CI tests, etc. So I guess that
most users just go for "Bug Report".
Alex
On Fri, Jan 17, 2025 at 8:34 AM Michael Collado <co...@gmail.com>
wrote:
> I agree that tackling real issues in a timely manner is super important.
> That’s why I think it’s important to be judicious in labeling issues as
> “bugs”. When the queue becomes too noisy, people learn to ignore it and
> important things get missed. When given the choice between too much noise
> and too little signal, I tend to err on the side of eliminating the noise
> so that at least we develop the habit of looking at whatever does come
> through.
>
> I’m glad to see all the issues being filed and all the accompanying
> activity. I just think we should be clear on how we label things so
> everyone knows how to prioritize.
>
> Mike
>
> On Thu, Jan 16, 2025 at 11:26 PM Eric Maynard <er...@gmail.com>
> wrote:
>
> > No, actually I don't think we need to argue much. We should try to label
> > things correctly and the difference between what is a bug and what is
> not a
> > bug is typically evident.
> >
> > This is a bug, <https://github.com/apache/polaris/issues/813> and this
> is
> > not <https://github.com/apache/polaris/issues/773>. Both of these are
> > legitimate issues, but how they are labelled is important.
> >
> > On Thu, Jan 16, 2025 at 11:20 PM Robert Stupp <sn...@snazy.de> wrote:
> >
> > > We can argue a long time about labels and their usage and about the
> > > formal definition of those.
> > >
> > > What I think really matters is that the issues, especially real bugs,
> > > with security issues being the absolute #1 priority, are tackled in a
> > > timely manner.
> > >
> > > On 17.01.25 06:00, Jean-Baptiste Onofré wrote:
> > > > Hi Mike
> > > >
> > > > I agree, the bug label should mean: this is something breaking
> > > > *compared* to a previous commit (as we don't have release yet :)).
> The
> > > > GH Issues considering a "bug" not related to a previous commit is an
> > > > "improvement" to me: it's not a bug introduced on top of a previous
> > > > commit but more an "general concern/bug" we have in mind, so an
> > > > improvement on the existing.
> > > >
> > > > To sum-up:
> > > > - we should use "bug" for issue introduced by a commit after another
> > > > commit (history)
> > > > - we should use "improvement" for issue/improvement we want to
> > > > implement (it could be considered as a bug from a personal standpoint
> > > > but not related to project history)
> > > > - we should use "new feature" for new functionality we want to
> > > > implement in the project
> > > > - we should use "proposal" for design/MVP
> > > >
> > > > Regards
> > > > JB
> > > >
> > > > On Thu, Jan 16, 2025 at 10:56 PM Michael Collado <
> > collado.mike@gmail.com>
> > > wrote:
> > > >> Hey folks
> > > >>
> > > >> There are over 40 issues with the "bug" label in github right now,
> > many
> > > of
> > > >> which are not actually bugs, but seem to me like personal
> preferences
> > or
> > > >> possible improvements. A lot of these issues seem like reasonable or
> > > good
> > > >> changes to me, but I think we should reserve the "bug" label for
> > things
> > > >> that are actual bugs. Can we remove the bug label from issues that
> > > aren't
> > > >> actually broken?
> > > >>
> > > >> Mike
> > >
> > > --
> > > Robert Stupp
> > > @snazy
> > >
> > >
> >
>
Re: Use of the "bug" label in Github issues
Posted by Michael Collado <co...@gmail.com>.
I agree that tackling real issues in a timely manner is super important.
That’s why I think it’s important to be judicious in labeling issues as
“bugs”. When the queue becomes too noisy, people learn to ignore it and
important things get missed. When given the choice between too much noise
and too little signal, I tend to err on the side of eliminating the noise
so that at least we develop the habit of looking at whatever does come
through.
I’m glad to see all the issues being filed and all the accompanying
activity. I just think we should be clear on how we label things so
everyone knows how to prioritize.
Mike
On Thu, Jan 16, 2025 at 11:26 PM Eric Maynard <er...@gmail.com>
wrote:
> No, actually I don't think we need to argue much. We should try to label
> things correctly and the difference between what is a bug and what is not a
> bug is typically evident.
>
> This is a bug, <https://github.com/apache/polaris/issues/813> and this is
> not <https://github.com/apache/polaris/issues/773>. Both of these are
> legitimate issues, but how they are labelled is important.
>
> On Thu, Jan 16, 2025 at 11:20 PM Robert Stupp <sn...@snazy.de> wrote:
>
> > We can argue a long time about labels and their usage and about the
> > formal definition of those.
> >
> > What I think really matters is that the issues, especially real bugs,
> > with security issues being the absolute #1 priority, are tackled in a
> > timely manner.
> >
> > On 17.01.25 06:00, Jean-Baptiste Onofré wrote:
> > > Hi Mike
> > >
> > > I agree, the bug label should mean: this is something breaking
> > > *compared* to a previous commit (as we don't have release yet :)). The
> > > GH Issues considering a "bug" not related to a previous commit is an
> > > "improvement" to me: it's not a bug introduced on top of a previous
> > > commit but more an "general concern/bug" we have in mind, so an
> > > improvement on the existing.
> > >
> > > To sum-up:
> > > - we should use "bug" for issue introduced by a commit after another
> > > commit (history)
> > > - we should use "improvement" for issue/improvement we want to
> > > implement (it could be considered as a bug from a personal standpoint
> > > but not related to project history)
> > > - we should use "new feature" for new functionality we want to
> > > implement in the project
> > > - we should use "proposal" for design/MVP
> > >
> > > Regards
> > > JB
> > >
> > > On Thu, Jan 16, 2025 at 10:56 PM Michael Collado <
> collado.mike@gmail.com>
> > wrote:
> > >> Hey folks
> > >>
> > >> There are over 40 issues with the "bug" label in github right now,
> many
> > of
> > >> which are not actually bugs, but seem to me like personal preferences
> or
> > >> possible improvements. A lot of these issues seem like reasonable or
> > good
> > >> changes to me, but I think we should reserve the "bug" label for
> things
> > >> that are actual bugs. Can we remove the bug label from issues that
> > aren't
> > >> actually broken?
> > >>
> > >> Mike
> >
> > --
> > Robert Stupp
> > @snazy
> >
> >
>
Re: Use of the "bug" label in Github issues
Posted by Robert Stupp <sn...@snazy.de>.
On 17.01.25 08:26, Eric Maynard wrote:
> No, actually I don't think we need to argue much. We should try to label
> things correctly and the difference between what is a bug and what is not a
> bug is typically evident.
Well, then let's stop arguing.
> This is a bug, <https://github.com/apache/polaris/issues/813> and this is
> not <https://github.com/apache/polaris/issues/773>. Both of these are
> legitimate issues, but how they are labelled is important.
I could argue that 773 is a performance issue.
But yea - let's stop arguing about labels.
> On Thu, Jan 16, 2025 at 11:20 PM Robert Stupp <sn...@snazy.de> wrote:
>
>> We can argue a long time about labels and their usage and about the
>> formal definition of those.
>>
>> What I think really matters is that the issues, especially real bugs,
>> with security issues being the absolute #1 priority, are tackled in a
>> timely manner.
>>
>> On 17.01.25 06:00, Jean-Baptiste Onofré wrote:
>>> Hi Mike
>>>
>>> I agree, the bug label should mean: this is something breaking
>>> *compared* to a previous commit (as we don't have release yet :)). The
>>> GH Issues considering a "bug" not related to a previous commit is an
>>> "improvement" to me: it's not a bug introduced on top of a previous
>>> commit but more an "general concern/bug" we have in mind, so an
>>> improvement on the existing.
>>>
>>> To sum-up:
>>> - we should use "bug" for issue introduced by a commit after another
>>> commit (history)
>>> - we should use "improvement" for issue/improvement we want to
>>> implement (it could be considered as a bug from a personal standpoint
>>> but not related to project history)
>>> - we should use "new feature" for new functionality we want to
>>> implement in the project
>>> - we should use "proposal" for design/MVP
>>>
>>> Regards
>>> JB
>>>
>>> On Thu, Jan 16, 2025 at 10:56 PM Michael Collado <co...@gmail.com>
>> wrote:
>>>> Hey folks
>>>>
>>>> There are over 40 issues with the "bug" label in github right now, many
>> of
>>>> which are not actually bugs, but seem to me like personal preferences or
>>>> possible improvements. A lot of these issues seem like reasonable or
>> good
>>>> changes to me, but I think we should reserve the "bug" label for things
>>>> that are actual bugs. Can we remove the bug label from issues that
>> aren't
>>>> actually broken?
>>>>
>>>> Mike
>> --
>> Robert Stupp
>> @snazy
>>
>>
--
Robert Stupp
@snazy
Re: Use of the "bug" label in Github issues
Posted by Eric Maynard <er...@gmail.com>.
No, actually I don't think we need to argue much. We should try to label
things correctly and the difference between what is a bug and what is not a
bug is typically evident.
This is a bug, <https://github.com/apache/polaris/issues/813> and this is
not <https://github.com/apache/polaris/issues/773>. Both of these are
legitimate issues, but how they are labelled is important.
On Thu, Jan 16, 2025 at 11:20 PM Robert Stupp <sn...@snazy.de> wrote:
> We can argue a long time about labels and their usage and about the
> formal definition of those.
>
> What I think really matters is that the issues, especially real bugs,
> with security issues being the absolute #1 priority, are tackled in a
> timely manner.
>
> On 17.01.25 06:00, Jean-Baptiste Onofré wrote:
> > Hi Mike
> >
> > I agree, the bug label should mean: this is something breaking
> > *compared* to a previous commit (as we don't have release yet :)). The
> > GH Issues considering a "bug" not related to a previous commit is an
> > "improvement" to me: it's not a bug introduced on top of a previous
> > commit but more an "general concern/bug" we have in mind, so an
> > improvement on the existing.
> >
> > To sum-up:
> > - we should use "bug" for issue introduced by a commit after another
> > commit (history)
> > - we should use "improvement" for issue/improvement we want to
> > implement (it could be considered as a bug from a personal standpoint
> > but not related to project history)
> > - we should use "new feature" for new functionality we want to
> > implement in the project
> > - we should use "proposal" for design/MVP
> >
> > Regards
> > JB
> >
> > On Thu, Jan 16, 2025 at 10:56 PM Michael Collado <co...@gmail.com>
> wrote:
> >> Hey folks
> >>
> >> There are over 40 issues with the "bug" label in github right now, many
> of
> >> which are not actually bugs, but seem to me like personal preferences or
> >> possible improvements. A lot of these issues seem like reasonable or
> good
> >> changes to me, but I think we should reserve the "bug" label for things
> >> that are actual bugs. Can we remove the bug label from issues that
> aren't
> >> actually broken?
> >>
> >> Mike
>
> --
> Robert Stupp
> @snazy
>
>
Re: Use of the "bug" label in Github issues
Posted by Robert Stupp <sn...@snazy.de>.
We can argue a long time about labels and their usage and about the
formal definition of those.
What I think really matters is that the issues, especially real bugs,
with security issues being the absolute #1 priority, are tackled in a
timely manner.
On 17.01.25 06:00, Jean-Baptiste Onofré wrote:
> Hi Mike
>
> I agree, the bug label should mean: this is something breaking
> *compared* to a previous commit (as we don't have release yet :)). The
> GH Issues considering a "bug" not related to a previous commit is an
> "improvement" to me: it's not a bug introduced on top of a previous
> commit but more an "general concern/bug" we have in mind, so an
> improvement on the existing.
>
> To sum-up:
> - we should use "bug" for issue introduced by a commit after another
> commit (history)
> - we should use "improvement" for issue/improvement we want to
> implement (it could be considered as a bug from a personal standpoint
> but not related to project history)
> - we should use "new feature" for new functionality we want to
> implement in the project
> - we should use "proposal" for design/MVP
>
> Regards
> JB
>
> On Thu, Jan 16, 2025 at 10:56 PM Michael Collado <co...@gmail.com> wrote:
>> Hey folks
>>
>> There are over 40 issues with the "bug" label in github right now, many of
>> which are not actually bugs, but seem to me like personal preferences or
>> possible improvements. A lot of these issues seem like reasonable or good
>> changes to me, but I think we should reserve the "bug" label for things
>> that are actual bugs. Can we remove the bug label from issues that aren't
>> actually broken?
>>
>> Mike
--
Robert Stupp
@snazy
Re: Use of the "bug" label in Github issues
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Mike
I agree, the bug label should mean: this is something breaking
*compared* to a previous commit (as we don't have release yet :)). The
GH Issues considering a "bug" not related to a previous commit is an
"improvement" to me: it's not a bug introduced on top of a previous
commit but more an "general concern/bug" we have in mind, so an
improvement on the existing.
To sum-up:
- we should use "bug" for issue introduced by a commit after another
commit (history)
- we should use "improvement" for issue/improvement we want to
implement (it could be considered as a bug from a personal standpoint
but not related to project history)
- we should use "new feature" for new functionality we want to
implement in the project
- we should use "proposal" for design/MVP
Regards
JB
On Thu, Jan 16, 2025 at 10:56 PM Michael Collado <co...@gmail.com> wrote:
>
> Hey folks
>
> There are over 40 issues with the "bug" label in github right now, many of
> which are not actually bugs, but seem to me like personal preferences or
> possible improvements. A lot of these issues seem like reasonable or good
> changes to me, but I think we should reserve the "bug" label for things
> that are actual bugs. Can we remove the bug label from issues that aren't
> actually broken?
>
> Mike