I think that would be a perfect reason to comment on those issues and
mention that they are still relevant. The stalebot message even invites you
to do so. IMO, one of the services provided by the stalebot is to remind
people to take a look at older issues and check if they are still relevant,
otherwise they would be likely to sit open forever with nobody reviewing
them.
On Thu, Jul 4, 2019 at 9:06 PM Prashant Deva <prashant.d...@gmail.com>
wrote:
> 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
>
