I like it, helps clean up a lot of noise and the issues that are no longer
relevant or important.

On Wed, Jul 24, 2019 at 10:33 PM Gian Merlino <g...@apache.org> wrote:

> Hi, just wanted to check in how people think the stalebot for issues has
> been working out (positive, negative, don't know yet)? It's been running
> for about a month.
>
> On Mon, Jul 15, 2019 at 2:33 PM Gian Merlino <g...@apache.org> wrote:
>
> > I wrote a comment on the issue, about considering a different exempt list
> > for issues vs PRs.
> >
> > On Mon, Jul 15, 2019 at 10:07 AM Roman Leventov <leventov...@gmail.com>
> > wrote:
> >
> >> I've proposed to add more exempt labels and set the closing timeout to
> 28
> >> days here: https://github.com/apache/incubator-druid/pull/8084.
> >>
> >> On Sat, 6 Jul 2019 at 01:35, Gian Merlino <g...@apache.org> wrote:
> >>
> >> > You raise a good point but I don't think leaving issues open with no
> >> > response forever is a good solution either. That's probably what would
> >> have
> >> > happened to your issues if we didn't have a stalebot. The ideal thing
> >> is to
> >> > strive to respond to every reported issue, which hopefully we can pull
> >> > together as a community to do.
> >> >
> >> > On Fri, Jul 5, 2019 at 3:22 PM Prashant Deva <prashant.d...@gmail.com
> >
> >> > wrote:
> >> >
> >> > > i agree with you, but do consider the following case:
> >> > >
> >> > > I am new to druid. I report the above 2 bugs. They don’t get a
> >> response.
> >> > > Then a bot closes them automatically.
> >> > > As a new user, I may then not be motivated to report further bugs.
> >> > >
> >> > >
> >> > >
> >> > > On Thu, Jul 4, 2019 at 9:13 PM Gian Merlino <g...@apache.org>
> wrote:
> >> > >
> >> > > > 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
> >> > > > >
> >> > > >
> >> > > --
> >> > > Prashant
> >> > >
> >> >
> >>
> >
>

Reply via email to