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