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
