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