We could close all >1 month old issues as a one-time thing but first we really should have a proper process in place.
One thing we might have to consider is that there is a natural limit to how many package each core committer can handle and we have way too many packages right now. I know it's not pleasing to think of our limitations but maybe should consider trimming the herd in exchange for a better supported core of package. That's something that Arch does for example. On Fri, 22 Jul 2016 at 13:25 Wout Mertens <wout.mert...@gmail.com> wrote: > > One day I closed an issue because nobody cared for months (even I > didn't care enough even though I reported it). Someone reopened it saying > that a lack of care was not a reason to close an issue and someone else > fixed the issue the same day. So, closing can even encourage fixing :-). > > Which is exactly my point. 14 days is long enough for people to chime in, > and if it gets closed all the interested parties get a reminder to reopen > it if they still care. Autoclose is not the same as close. > > We could run this tool first with a 1-year timeout, then one week later 6 > months etc until we get to 14 days, so that people are not overwhelmed by > all the close notices. > > On Fri, Jul 22, 2016 at 2:20 PM Tomasz Czyż <tomasz.c...@gmail.com> wrote: > >> https://github.com/kubernetes/kubernetes - just adding as reference :-) >> >> >> 2016-07-22 12:07 GMT+01:00 zimbatm <zimb...@zimbatm.com>: >> >>> Exactly, we need to organize ourselves better. For me 1k+ open issues is >>> also a bad signal when I consider adopting a project. Closing them all is >>> not going to actually fix these issues, what we need is more helping hands! >>> >>> Here are a couple of aspects that I think are part of the problem: >>> >>> Github issues doesn't let us forward packaging issues to the package >>> maintainer which is the best person to fix these issues. Some might be easy >>> fixed that just didn't reach the right audience. I tried subscribing to the >>> repo but there is way too much volume for me to handle. >>> >>> Another similar issue is that the submitting person can't set flags on >>> the new issue he's creating. We have to rely on a core contributor for >>> doing that work instead, which is a waste of resource. >>> >>> Right now participation is really random and it's nice to keep this >>> freedom but would anyone else be willing to setup a rota? If we can be more >>> consistent on the response times I think it would be beneficial. >>> >>> What's our process to make sure issues don't fall trough the cracks? >>> Just writing a playbook on how to become the "ideal" maintainer would be >>> helpful I think. >>> >>> Hmm that's it for now ^_^ >>> >>> >>> >>> On Fri, 22 Jul 2016 at 11:04 Domen Kožar <do...@dev.si> wrote: >>> >>>> The real question is how to organize so that we triage all incoming >>>> issues. Closing them is the easy part :) >>>> >>>> On Fri, Jul 22, 2016 at 11:52 AM, Wout Mertens <wout.mert...@gmail.com> >>>> wrote: >>>> >>>>> We could tag those issues with "mayor-unsolved-issue" and search for >>>>> them that way. Unsolvable issues are just standing in the way of solvable >>>>> ones, making it harder to keep the project up-to-date. >>>>> >>>>> On Fri, Jul 22, 2016 at 11:49 AM Roger Qiu <roger....@matrix.ai> >>>>> wrote: >>>>> >>>>>> What about things that aren't necessarily small fixable bugs. Some >>>>>> projects have long discussions about design or philosophy or some major >>>>>> architecting. Or a bug that is pending somebody coming up with a good >>>>>> solution (like for example ZFS's encryption issue which was open for >>>>>> years). Will people need to constantly comment with `+1` just to reopen? >>>>>> Also if an issue is closed it may increase the number of duplicate >>>>>> issues, >>>>>> instead of adding onto the closed issue. >>>>>> >>>>>> On 22/07/2016 7:37 PM, Wout Mertens wrote: >>>>>> >>>>>> That's the thing about auto-reopening, it makes sure that people >>>>>> interested in seeing the issue fixed are reminded of the issue so they >>>>>> can >>>>>> continue fixing it, as well as automatically weeding out the issues that >>>>>> are no longer important. >>>>>> >>>>>> All the *real* issues will stay active, since people will reopen >>>>>> them. All the rest will be available in the history. >>>>>> >>>>>> I think 14 days is enough time between reminders for an open source >>>>>> project. Shorter is annoying since we can't work on open source every >>>>>> day, >>>>>> and longer will just lead to more stale issues. >>>>>> >>>>>> On Fri, Jul 22, 2016 at 11:17 AM Oliver Charles < >>>>>> ol...@ocharles.org.uk> wrote: >>>>>> >>>>>>> Agreed. >>>>>>> >>>>>>> But if the problem is you think old issues are skewing the >>>>>>> results/making it hard to find the signal, then can't you just use more >>>>>>> intelligent search filters? E.g., things created in the past 3 months. >>>>>>> >>>>>>> On Fri, Jul 22, 2016 at 10:15 AM Eelco Dolstra < >>>>>>> eelco.dols...@logicblox.com> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> On 07/22/2016 09:06 AM, Wout Mertens wrote: >>>>>>>> >>>>>>>> > We have 1238 open issues and 286 open PRs. >>>>>>>> > >>>>>>>> > That is just too much to reason about. >>>>>>>> > >>>>>>>> > How about using something like https://github.com/twbs/no-carrier >>>>>>>> which >>>>>>>> > auto-closes after 14 days of inactivity, and reopens on a new >>>>>>>> comment? >>>>>>>> >>>>>>>> There is something to be said for auto-closing issues after a long >>>>>>>> time (e.g. >>>>>>>> Fedora auto-closes inactive issues from CURRENT-2 releases ago), >>>>>>>> but 14 days is >>>>>>>> waaaay to short. Bugs don't disappear after 14 days... >>>>>>>> >>>>>>>> -- >>>>>>>> Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/ >>>>>>>> _______________________________________________ >>>>>>>> nix-dev mailing list >>>>>>>> nix-dev@lists.science.uu.nl >>>>>>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> nix-dev mailing list >>>>>>> nix-dev@lists.science.uu.nl >>>>>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> nix-dev mailing >>>>>> listnix-...@lists.science.uu.nlhttp://lists.science.uu.nl/mailman/listinfo/nix-dev >>>>>> >>>>>> >>>>>> -- >>>>>> Founder of Matrix AIhttps://matrix.ai/+61420925975 >>>>>> >>>>>> _______________________________________________ >>>>>> nix-dev mailing list >>>>>> nix-dev@lists.science.uu.nl >>>>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev >>>>>> >>>>> >>>>> _______________________________________________ >>>>> nix-dev mailing list >>>>> nix-dev@lists.science.uu.nl >>>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev >>>>> >>>>> >>>> _______________________________________________ >>>> nix-dev mailing list >>>> nix-dev@lists.science.uu.nl >>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev >>>> >>> >>> _______________________________________________ >>> nix-dev mailing list >>> nix-dev@lists.science.uu.nl >>> http://lists.science.uu.nl/mailman/listinfo/nix-dev >>> >>> >> >> >> -- >> Tomasz Czyż >> >
_______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev