https://github.com/kubernetes/kubernetes - just adding as reference :-)
2016-07-22 12:07 GMT+01:00 zimbatm <[email protected]>: > 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> 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 <[email protected]> >>>> 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 < >>>>> [email protected]> 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 >>>>>> [email protected] >>>>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev >>>>>> >>>>> _______________________________________________ >>>>> nix-dev mailing list >>>>> [email protected] >>>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> nix-dev mailing >>>> [email protected]http://lists.science.uu.nl/mailman/listinfo/nix-dev >>>> >>>> >>>> -- >>>> Founder of Matrix AIhttps://matrix.ai/+61420925975 >>>> >>>> _______________________________________________ >>>> nix-dev mailing list >>>> [email protected] >>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev >>>> >>> >>> _______________________________________________ >>> nix-dev mailing list >>> [email protected] >>> http://lists.science.uu.nl/mailman/listinfo/nix-dev >>> >>> >> _______________________________________________ >> nix-dev mailing list >> [email protected] >> http://lists.science.uu.nl/mailman/listinfo/nix-dev >> > > _______________________________________________ > nix-dev mailing list > [email protected] > http://lists.science.uu.nl/mailman/listinfo/nix-dev > > -- Tomasz Czyż
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
