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