> 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
>
>
