stalebot just closed my issues 7473 and 7521.
Both bugs are still present.
they were closed because the bug reports themselves didn’t receive a reply.
Not receiving a reply did not make the bugs go away. Yet due to stalebot,
the bugs are now closed.
On Wed, Jun 26, 2019 at 10:28 AM Roman Leventov <leventov...@gmail.com>
wrote:
> > To me it makes sense to close even "Feature" ideas that have no
> > constituency, since it is just clutter to have a bunch of feature ideas
> > around that nobody is actively pushing.
>
> I have experience as a user (feature asker) of projects which adopt this
> policy and it always feels bad to me when my issue is closed "due to lack
> of activity". What activity do they expect? I'm not a developer of this
> project so, realistically, I cannot contribute to it. However, the problem
> is real and it causes real pain when I use the product (project, library,
> etc). So it always feels to me that the developers just want to feel
> comfortable (as described in the stalebot's documentation cited above in
> this thread) and see a small number of open issues at the expense of
> alienating users to some little extent. So, IMO, it's better to fix our
> perception instead about a large and ever-growing number of issues.
>
> > "Performance" and "Refactoring" makes more sense to consider evergreen
>
> Then "Improvement" should be there, too ("Performance" and "Refactoring"
> are just special cases of "Improvement"), as well as regular "Area - "
> tags, because "Improvement" is often omitted: generic "improvement" is the
> default intention of an issue unless tagged to something different (such as
> "bug").
>
> > Without that, some perfectly good ideas might be totally forgotten, open
> forever but never looked at. I'm ok either way on these two labels, I
> suppose.
>
> Perhaps issue priorities is a better tool for tackling this rather than
> regular notification of just the author of the issue. Tags give visibility
> for other developers and provide a way to browse the pool of impactful
> ideas. Priorities used to be used in the past but then people stopped using
> them. The only problem with priorities that I see is that they are
> subjective. "Impact/effort ratio" is something more objective.
>
> On Tue, 25 Jun 2019 at 21:07, Julian Hyde <jh...@apache.org> wrote:
>
> > I claim that features have a different lifecycle to bugs. There may not
> be
> > a strong case for doing a particular feature today, but in a year, there
> > may be a greater demand. If a bugs are not fixed, their importance
> usually
> > declines over time.
> >
> > Are people able to vote for features in GitHub issues? Are they able to
> > vote to them if they are closed? I think it’s useful for people to
> continue
> > to chime in on features, and eventually build consensus about what should
> > be built.
> >
> > Perhaps a label “not on roadmap” on a feature is all that is necessary to
> > manage people’s expectations. I agree that closing bugs makes sense
> because
> > (for some reason!) users assume that developers intend to fix every
> single
> > bug.
> >
> > Julian
> >
> >
> >
> > > On Jun 25, 2019, at 8:55 AM, Gian Merlino <g...@apache.org> wrote:
> > >
> > > To me it makes sense to close even "Feature" ideas that have no
> > > constituency, since it is just clutter to have a bunch of feature ideas
> > > around that nobody is actively pushing. However this starts to remind
> me
> > of
> > > the Wikipedia "deletionism vs. inclusionism" debate:
> > >
> https://en.wikipedia.org/wiki/Deletionism_and_inclusionism_in_Wikipedia
> > which
> > > simmers even to this day.
> > >
> > > "Performance" and "Refactoring" makes more sense to consider evergreen,
> > > although there may still be some benefit in stalebotting them anyway,
> > since
> > > the bot bumps things periodically to encourage reconsideration. Without
> > > that, some perfectly good ideas might be totally forgotten, open
> forever
> > > but never looked at. I'm ok either way on these two labels, I suppose.
> > >
> > >
> > > On Mon, Jun 24, 2019 at 11:36 AM Roman Leventov <leventov...@gmail.com
> >
> > > wrote:
> > >
> > >> I wrote previous messages in this thread before I've discovered that
> the
> > >> stalebot send me more than 100 messages. (That shouldn't be surprising
> > >> since I'm the author of 174 open issues in Druid:
> > >>
> > >>
> >
> https://github.com/apache/incubator-druid/search?p=1&q=is%3Aopen+author%3Aleventov+is%3Aissue&type=Issues
> > >> ).
> > >> As an experiment, I'll try to go over all notifications and post here
> > how
> > >> many of them can actually be closed now.
> > >>
> > >> On the other hand, I've realized that a big and a legitimate case for
> > >> stalebot closing issues are the issues of "Problem report" kind (
> > >>
> > >>
> >
> https://github.com/apache/incubator-druid/issues/new?assignees=&template=problem_report.md&title=
> > >> ).
> > >> The reasoning is that
> > >> - As time passes, the issue may be fixed in the newer Druid versions.
> > >> - The report may be irreproducible or hardly reproducible, especially
> if
> > >> the Druid version used is unspecified or there is otherwise too little
> > >> information in the issue.
> > >>
> > >> "Flaky test" issues are somewhat similar, too.
> > >>
> > >> Jon once suggested to add a "Problem report" tag:
> > >>
> > >>
> >
> https://lists.apache.org/thread.html/61068635cc338dd0da6d43bfca16adf9ccdd3d61e267b598124ca3ad@%3Cdev.druid.apache.org%3E
> > >> .
> > >> We could revive this idea in the form of "Uncategorized problem
> > report". It
> > >> would be a committer's duty to reassign either to "bug", "invalid", or
> > >> "won't fix" upon verification.
> > >>
> > >> Then, I suggest that the stalebot only watches "Uncategorized problem
> > >> report", "Flaky test", and issues without any tags (that would sweep
> all
> > >> old issues which are essentially uncategorized problem reports, as
> well
> > as
> > >> new issues when the authors use the "Other" button instead of "Problem
> > >> report" button).
> > >>
> > >> I think that the majority of "Feature/Change request", "Feature",
> > >> "Refactoring", "Performance", etc. issues would be "evergreen", so
> it's
> > >> more practically to close them only by occasion when someone visits
> > these
> > >> old issues.
> > >>
> > >> On Fri, 21 Jun 2019 at 21:57, Gian Merlino <g...@apache.org> wrote:
> > >>
> > >>> The core idea is that it's good for someone or something to go
> through
> > >> old
> > >>> issues periodically and clean up anything that's no longer relevant,
> > >> since
> > >>> having a bunch of irrelevant issues lying around is poor project
> > hygiene.
> > >>> No human is really volunteering for this, hence the bot. The fact
> that
> > it
> > >>> bumps things before closing them is useful too, since it sort of
> forces
> > >>> periodic re-consideration of relevancy.
> > >>>
> > >>>>> The effect should be giving us an
> > >>>>> open issues list that more accurately respects the issues that
> people
> > >>> in
> > >>>>> the community feel are important.
> > >>>>>
> > >>>> The list would still be too long to be comprehensible or digestible
> > for
> > >>>> anybody, nor that anyone is expected to go through the full list at
> > any
> > >>>> time.
> > >>>
> > >>> Maybe so, but I would really hope that with a shorter list, it could
> > >>> potentially be more digestible. At least wouldn't have a large amount
> > of
> > >>> irrelevant issues. If you look through our older issues, so many of
> > them
> > >>> are irrelevant or questionably relevant to today's Druid. This is
> fine
> > if
> > >>> nobody ever looks at them, which is probably the case for regular
> > >>> contributors, who I assume mostly interact with issues through
> > >>> notifications. But it can be misleading to those that don't pay
> > attention
> > >>> to the project every day.
> > >>>
> > >>>> Personally, I open many issues
> > >>>> which I don't really plan to work on in any foreseeable future, just
> > to
> > >>>> record my ideas and thoughts so that they can be discovered by other
> > >>>> developers (and myself) later, and referenced to from future
> > >> discussions,
> > >>>> issues, and PRs. I see a real practical value in it, as I routinely
> > >> link
> > >>> to
> > >>>> my own old issues (and re-read them, refreshing my old thoughts on
> the
> > >>>> topic) in Druid development. I don't want to take on a burden of
> > >>> regularly
> > >>>> repel the stalebot from all of these issues.
> > >>>
> > >>> This is a tough one. I did think about it and there are ups and
> downs.
> > >> The
> > >>> upside of stalebot in this case is that these 'idea and thoughts'
> > issues
> > >>> can become irrelevant over time (the underlying area of code has been
> > >>> refactored and nobody updated the issue, etc) and so it's good to
> close
> > >>> issues that may no longer be relevant. The downside is that the 'idea
> > and
> > >>> thoughts' issues tend to naturally be dormant for a long time, and
> the
> > >>> stalebot can be annoying. There is a label "Evergreen" that can be
> used
> > >> to
> > >>> ward off the stalebot (it will ignore anything with that label) that
> > can
> > >> be
> > >>> used to solve the latter problem. It's probably not good to have a
> ton
> > of
> > >>> issues labeled this way, since they can become irrelevant over time,
> > but
> > >> it
> > >>> is an option. The stalebot can be configured (and is configured) to
> > >> ignore
> > >>> issues that are part of projects, that have assignees, or that have
> > >>> milestones, so those are options too if they make sense.
> > >>>
> > >>>
> > >>> On Fri, Jun 21, 2019 at 9:07 AM Roman Leventov <
> leventov...@gmail.com>
> > >>> wrote:
> > >>>
> > >>>> On Fri, 21 Jun 2019 at 18:38, Gian Merlino <g...@apache.org> wrote:
> > >>>>
> > >>>>> The effect should be giving us an
> > >>>>> open issues list that more accurately respects the issues that
> people
> > >>> in
> > >>>>> the community feel are important.
> > >>>>>
> > >>>>
> > >>>> The list would still be too long to be comprehensible or digestible
> > for
> > >>>> anybody, nor that anyone is expected to go through the full list at
> > any
> > >>>> time.
> > >>>>
> > >>>> I see the value of nudging PR authors to push their work through
> > rather
> > >>>> than abandon PRs in pursuit of something new, hoping to return to
> the
> > >>> older
> > >>>> PRs later (which will likely never happen) - that is, to avoid this
> > >>>> psychological fallacy.
> > >>>>
> > >>>> But I don't see the same value for issues. Personally, I open many
> > >> issues
> > >>>> which I don't really plan to work on in any foreseeable future, just
> > to
> > >>>> record my ideas and thoughts so that they can be discovered by other
> > >>>> developers (and myself) later, and referenced to from future
> > >> discussions,
> > >>>> issues, and PRs. I see a real practical value in it, as I routinely
> > >> link
> > >>> to
> > >>>> my own old issues (and re-read them, refreshing my old thoughts on
> the
> > >>>> topic) in Druid development. I don't want to take on a burden of
> > >>> regularly
> > >>>> repel the stalebot from all of these issues.
> > >>>>
> > >>>>
> > >>>>> As more and more work piles up, it becomes paralyzing.
> > >>>>
> > >>>>
> > >>>> What I suggest is to embrace the fact that open issues list will
> grow
> > >> as
> > >>>> long as the project exists and don't be paralyzed. Why would a
> number
> > >> in
> > >>> a
> > >>>> circle in Github interface paralyze anybody from doing work, anyway?
> > >>>>
> > >>>>
> > >>>>> Just making decisions about what work should and shouldn't get
> > >>>>> done can exhaust all available resources.
> > >>>>
> > >>>>
> > >>>> This statement doesn't make sense to me as well as the previous
> one. I
> > >>>> actually agree that priorities and focus is an important issue for a
> > >>>> project like Druid where there are a lot of directions in which it
> can
> > >> be
> > >>>> improved and it's hard to choose (predict) the direction with the
> > >> highest
> > >>>> ROI. But I don't see how going down from 1000 to 100 open issues
> would
> > >>> help
> > >>>> with this challenge at all.
> > >>>>
> > >>>> As a compromise approach, I suggest to auto-tag issues as "Shelved",
> > >>>> although, personally, I don't see the point in that either, but if
> > >> other
> > >>>> people want to see if there is any recent activity on the issue, it
> > >> might
> > >>>> be helpful.
> > >>>>
> > >>>
> > >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@druid.apache.org
> > For additional commands, e-mail: dev-h...@druid.apache.org
> >
> >
>
--
Prashant
