[Nix-dev] Too many open issues

Fri Jul 22 15:01:30 CEST 2016

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.mertens at 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.czyz at gmail.com> wrote:
>
>> https://github.com/kubernetes/kubernetes - just adding as reference :-)
>>
>>
>> 2016-07-22 12:07 GMT+01:00 zimbatm <zimbatm at 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 <domen at 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.mertens at 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.qiu at 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 <
>>>>>> ollie at 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.dolstra at 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 at lists.science.uu.nl
>>>>>>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> nix-dev mailing list
>>>>>>> nix-dev at lists.science.uu.nl
>>>>>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> nix-dev mailing listnix-dev at 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 at lists.science.uu.nl
>>>>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> nix-dev mailing list
>>>>> nix-dev at lists.science.uu.nl
>>>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>>>>
>>>>>
>>>> _______________________________________________
>>>> nix-dev mailing list
>>>> nix-dev at lists.science.uu.nl
>>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>>>
>>>
>>> _______________________________________________
>>> nix-dev mailing list
>>> nix-dev at lists.science.uu.nl
>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>>
>>>
>>
>>
>> --
>> Tomasz Czyż
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160722/31f1fdd4/attachment-0001.html>