You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@druid.apache.org by Gian Merlino <gi...@apache.org> on 2019/06/20 19:40:00 UTC
Stalebot for issues
There's been some discussion on GitHub about enabling stalebot (which we
use for PRs) for issues as well. Please check this PR out if you are
interested: https://github.com/apache/incubator-druid/pull/7936. It's a
follow up to https://github.com/apache/incubator-druid/pull/7927, which is
also recent.
Re: Stalebot for issues
Posted by Fangjin Yang <fa...@imply.io>.
Roman - I don't believe a compromise is required here and I am strongly in
favor of Gian's approach.
On Fri, Jun 21, 2019 at 9:07 AM Roman Leventov <le...@gmail.com>
wrote:
> On Fri, 21 Jun 2019 at 18:38, Gian Merlino <gi...@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.
>
Re: Stalebot for issues
Posted by Himanshu <g....@gmail.com>.
Positive: I like that old and buried issues are getting some attention
because they get commented on.
Negative: Of course, it is a bit of work for authors to re-open them
specially when you get a lot of stale bot notifications in same day. Not
sure if stale bot has a randomization feature where we can set time ranges
instead of number of days to mark stale and close, maybe that could reduce
number of notifications in same day. I am aware of tags to skip issues from
stalebot but that is a workaround which takes away the "Positive" mentioned
above.
On Thu, Jul 25, 2019 at 8:38 AM Fangjin Yang <fa...@imply.io> wrote:
> 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 <gi...@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 <gi...@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.ru@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 <gi...@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.deva@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 <gi...@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.deva@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.ru@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 <jhyde@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 <
> > gian@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.ru@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 <
> > >> gian@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.ru@gmail.com>
> > >> > > > > > > >>> wrote:
> > >> > > > > > > >>>
> > >> > > > > > > >>>> On Fri, 21 Jun 2019 at 18:38, Gian Merlino <
> > >> gian@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-unsubscribe@druid.apache.org
> > >> > > > > > > For additional commands, e-mail:
> dev-help@druid.apache.org
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > > >
> > >> > > > > --
> > >> > > > > Prashant
> > >> > > > >
> > >> > > >
> > >> > > --
> > >> > > Prashant
> > >> > >
> > >> >
> > >>
> > >
> >
>
Re: Stalebot for issues
Posted by Fangjin Yang <fa...@imply.io>.
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 <gi...@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 <gi...@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 <le...@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 <gi...@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.deva@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 <gi...@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.deva@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.ru@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 <
> gian@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.ru@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 <
> >> gian@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.ru@gmail.com>
> >> > > > > > > >>> wrote:
> >> > > > > > > >>>
> >> > > > > > > >>>> On Fri, 21 Jun 2019 at 18:38, Gian Merlino <
> >> gian@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-unsubscribe@druid.apache.org
> >> > > > > > > For additional commands, e-mail: dev-help@druid.apache.org
> >> > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > > --
> >> > > > > Prashant
> >> > > > >
> >> > > >
> >> > > --
> >> > > Prashant
> >> > >
> >> >
> >>
> >
>
Re: Stalebot for issues
Posted by Gian Merlino <gi...@apache.org>.
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 <gi...@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 <le...@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 <gi...@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 <pr...@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 <gi...@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.deva@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.ru@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 <gi...@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.ru@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 <
>> gian@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.ru@gmail.com>
>> > > > > > > >>> wrote:
>> > > > > > > >>>
>> > > > > > > >>>> On Fri, 21 Jun 2019 at 18:38, Gian Merlino <
>> gian@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-unsubscribe@druid.apache.org
>> > > > > > > For additional commands, e-mail: dev-help@druid.apache.org
>> > > > > > >
>> > > > > > >
>> > > > > >
>> > > > > --
>> > > > > Prashant
>> > > > >
>> > > >
>> > > --
>> > > Prashant
>> > >
>> >
>>
>
Re: Stalebot for issues
Posted by Gian Merlino <gi...@apache.org>.
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 <le...@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 <gi...@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 <pr...@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 <gi...@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.deva@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.ru@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 <gi...@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.ru@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 <gian@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.ru@gmail.com>
> > > > > > > >>> wrote:
> > > > > > > >>>
> > > > > > > >>>> On Fri, 21 Jun 2019 at 18:38, Gian Merlino <
> gian@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-unsubscribe@druid.apache.org
> > > > > > > For additional commands, e-mail: dev-help@druid.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > --
> > > > > Prashant
> > > > >
> > > >
> > > --
> > > Prashant
> > >
> >
>
Re: Stalebot for issues
Posted by Roman Leventov <le...@gmail.com>.
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 <gi...@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 <pr...@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 <gi...@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 <pr...@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.ru@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 <gi...@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.ru@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 <gi...@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.ru@gmail.com>
> > > > > > >>> wrote:
> > > > > > >>>
> > > > > > >>>> On Fri, 21 Jun 2019 at 18:38, Gian Merlino <gian@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-unsubscribe@druid.apache.org
> > > > > > For additional commands, e-mail: dev-help@druid.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > --
> > > > Prashant
> > > >
> > >
> > --
> > Prashant
> >
>
Re: Stalebot for issues
Posted by Gian Merlino <gi...@apache.org>.
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 <pr...@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 <gi...@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 <pr...@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.ru@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 <gi...@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.ru@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 <gi...@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.ru@gmail.com>
> > > > > >>> wrote:
> > > > > >>>
> > > > > >>>> On Fri, 21 Jun 2019 at 18:38, Gian Merlino <gi...@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-unsubscribe@druid.apache.org
> > > > > For additional commands, e-mail: dev-help@druid.apache.org
> > > > >
> > > > >
> > > >
> > > --
> > > Prashant
> > >
> >
> --
> Prashant
>
Re: Stalebot for issues
Posted by Prashant Deva <pr...@gmail.com>.
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 <gi...@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 <pr...@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 <le...@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 <gi...@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.ru@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 <gi...@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.ru@gmail.com>
> > > > >>> wrote:
> > > > >>>
> > > > >>>> On Fri, 21 Jun 2019 at 18:38, Gian Merlino <gi...@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-unsubscribe@druid.apache.org
> > > > For additional commands, e-mail: dev-help@druid.apache.org
> > > >
> > > >
> > >
> > --
> > Prashant
> >
>
--
Prashant
Re: Stalebot for issues
Posted by Gian Merlino <gi...@apache.org>.
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 <pr...@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 <le...@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 <gi...@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.ru@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 <gi...@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.ru@gmail.com>
> > > >>> wrote:
> > > >>>
> > > >>>> On Fri, 21 Jun 2019 at 18:38, Gian Merlino <gi...@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-unsubscribe@druid.apache.org
> > > For additional commands, e-mail: dev-help@druid.apache.org
> > >
> > >
> >
> --
> Prashant
>
Re: Stalebot for issues
Posted by Prashant Deva <pr...@gmail.com>.
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 <le...@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 <gi...@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.ru@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 <gi...@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.ru@gmail.com>
> > >>> wrote:
> > >>>
> > >>>> On Fri, 21 Jun 2019 at 18:38, Gian Merlino <gi...@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-unsubscribe@druid.apache.org
> > For additional commands, e-mail: dev-help@druid.apache.org
> >
> >
>
--
Prashant
Re: Stalebot for issues
Posted by Roman Leventov <le...@gmail.com>.
> 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 <gi...@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 <le...@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 <gi...@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 <le...@gmail.com>
> >>> wrote:
> >>>
> >>>> On Fri, 21 Jun 2019 at 18:38, Gian Merlino <gi...@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-unsubscribe@druid.apache.org
> For additional commands, e-mail: dev-help@druid.apache.org
>
>
Re: Stalebot for issues
Posted by Julian Hyde <jh...@apache.org>.
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 <gi...@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 <le...@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 <gi...@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 <le...@gmail.com>
>>> wrote:
>>>
>>>> On Fri, 21 Jun 2019 at 18:38, Gian Merlino <gi...@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-unsubscribe@druid.apache.org
For additional commands, e-mail: dev-help@druid.apache.org
Re: Stalebot for issues
Posted by Gian Merlino <gi...@apache.org>.
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 <le...@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 <gi...@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 <le...@gmail.com>
> > wrote:
> >
> > > On Fri, 21 Jun 2019 at 18:38, Gian Merlino <gi...@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.
> > >
> >
>
Re: Stalebot for issues
Posted by Roman Leventov <le...@gmail.com>.
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 <gi...@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 <le...@gmail.com>
> wrote:
>
> > On Fri, 21 Jun 2019 at 18:38, Gian Merlino <gi...@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.
> >
>
Re: Stalebot for issues
Posted by Gian Merlino <gi...@apache.org>.
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 <le...@gmail.com>
wrote:
> On Fri, 21 Jun 2019 at 18:38, Gian Merlino <gi...@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.
>
Re: Stalebot for issues
Posted by Roman Leventov <le...@gmail.com>.
On Fri, 21 Jun 2019 at 18:38, Gian Merlino <gi...@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.
Re: Stalebot for issues
Posted by Gian Merlino <gi...@apache.org>.
To me, it's the same as the point of closing old PRs, which is (1) to
automatically "bump" in any dormant issue -- the stalebot will comment 2
weeks before closing, giving anyone an opportunity to state that it's still
relevant and bring it back to the forefront for re-consideration; (2) to
automatically close any issues that nobody wants to speak up for -- we have
a large number of issues that are no longer relevant, but just aren't
getting closed since nobody scrubs them. 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 stalebot documentation itself (https://github.com/probot/stale) has a
good justification:
> In an ideal world with infinite resources, there would be no need for
this app.
>
> But in any successful software project, there's always more work to do
than people to do it. As more and more work piles up, it becomes
paralyzing. Just making decisions about what work should and shouldn't get
done can exhaust all available resources. In the experience of the
maintainers of this app—and the hundreds of other projects and
organizations that use it—focusing on issues that are actively affecting
humans is an effective method for prioritizing work.
>
> To some, a robot trying to close stale issues may seem inhospitable or
offensive to contributors. But the alternative is to disrespect them by
setting false expectations and implicitly ignoring their work. This app
makes it explicit: if work is not progressing, then it's stale. A comment
is all it takes to keep the conversation alive.
On Fri, Jun 21, 2019 at 7:57 AM Roman Leventov <le...@gmail.com>
wrote:
> What's the purpose of closing old issues? How does it make the Druid
> development experience better?
>
> On Thu, 20 Jun 2019 at 23:54, Gian Merlino <gi...@apache.org> wrote:
>
> > By the way, I do think it makes sense to have a stalebot for issues.
> Right
> > now we have over 1000 open issues and I doubt anyone is actively
> reviewing
> > them. IMO it would be better to keep the list shorter, to things where
> the
> > original filer is still actively interested in keeping them alive. But I
> > think 60 days is a bit short, hence the suggestion in my follow up PR to
> > raise it to 280 days (about 3 release cycles).
> >
> > On Thu, Jun 20, 2019 at 12:40 PM Gian Merlino <gi...@apache.org> wrote:
> >
> > > There's been some discussion on GitHub about enabling stalebot (which
> we
> > > use for PRs) for issues as well. Please check this PR out if you are
> > > interested: https://github.com/apache/incubator-druid/pull/7936. It's
> a
> > > follow up to https://github.com/apache/incubator-druid/pull/7927,
> which
> > > is also recent.
> > >
> >
>
Re: Stalebot for issues
Posted by Roman Leventov <le...@gmail.com>.
What's the purpose of closing old issues? How does it make the Druid
development experience better?
On Thu, 20 Jun 2019 at 23:54, Gian Merlino <gi...@apache.org> wrote:
> By the way, I do think it makes sense to have a stalebot for issues. Right
> now we have over 1000 open issues and I doubt anyone is actively reviewing
> them. IMO it would be better to keep the list shorter, to things where the
> original filer is still actively interested in keeping them alive. But I
> think 60 days is a bit short, hence the suggestion in my follow up PR to
> raise it to 280 days (about 3 release cycles).
>
> On Thu, Jun 20, 2019 at 12:40 PM Gian Merlino <gi...@apache.org> wrote:
>
> > There's been some discussion on GitHub about enabling stalebot (which we
> > use for PRs) for issues as well. Please check this PR out if you are
> > interested: https://github.com/apache/incubator-druid/pull/7936. It's a
> > follow up to https://github.com/apache/incubator-druid/pull/7927, which
> > is also recent.
> >
>
Re: Stalebot for issues
Posted by Gian Merlino <gi...@apache.org>.
By the way, I do think it makes sense to have a stalebot for issues. Right
now we have over 1000 open issues and I doubt anyone is actively reviewing
them. IMO it would be better to keep the list shorter, to things where the
original filer is still actively interested in keeping them alive. But I
think 60 days is a bit short, hence the suggestion in my follow up PR to
raise it to 280 days (about 3 release cycles).
On Thu, Jun 20, 2019 at 12:40 PM Gian Merlino <gi...@apache.org> wrote:
> There's been some discussion on GitHub about enabling stalebot (which we
> use for PRs) for issues as well. Please check this PR out if you are
> interested: https://github.com/apache/incubator-druid/pull/7936. It's a
> follow up to https://github.com/apache/incubator-druid/pull/7927, which
> is also recent.
>