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