[Nix-dev] Too many open issues

[zimbatm]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160722/99571044/attachment-0001.html>