[prev in list] [next in list] [prev in thread] [next in thread]
List: nix-dev
Subject: Re: [Nix-dev] Too many open issues
From: zimbatm <zimbatm () zimbatm ! com>
Date: 2016-07-22 13:01:30
Message-ID: CANEP-f7F4C5ZvYFQ9GKej38kp+bSTD=Nj2LodpB2BEP+WYRM=w () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@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=C5=BC <tomasz.czyz@gmail.com> =
wrote:
>
>> https://github.com/kubernetes/kubernetes - just adding as reference :-)
>>
>>
>> 2016-07-22 12:07 GMT+01:00 zimbatm <zimbatm@zimbatm.com>:
>>
>>> Exactly, we need to organize ourselves better. For me 1k+ open issues i=
s
>>> 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 h=
ands!
>>>
>>> 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 b=
e
>>> helpful I think.
>>>
>>> Hmm that's it for now ^_^
>>>
>>>
>>>
>>> On Fri, 22 Jul 2016 at 11:04 Domen Ko=C5=BEar <domen@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@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 solv=
able
>>>>> ones, making it harder to keep the project up-to-date.
>>>>>
>>>>> On Fri, Jul 22, 2016 at 11:49 AM Roger Qiu <roger.qiu@matrix.ai>
>>>>> wrote:
>>>>>
>>>>>> What about things that aren't necessarily small fixable bugs. Some
>>>>>> projects have long discussions about design or philosophy or some ma=
jor
>>>>>> architecting. Or a bug that is pending somebody coming up with a goo=
d
>>>>>> solution (like for example ZFS's encryption issue which was open for
>>>>>> years). Will people need to constantly comment with `+1` just to reo=
pen?
>>>>>> Also if an issue is closed it may increase the number of duplicate i=
ssues,
>>>>>> 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 th=
ey 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 ever=
y day,
>>>>>> and longer will just lead to more stale issues.
>>>>>>
>>>>>> On Fri, Jul 22, 2016 at 11:17 AM Oliver Charles <
>>>>>> ollie@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 mont=
hs.
>>>>>>>
>>>>>>> On Fri, Jul 22, 2016 at 10:15 AM Eelco Dolstra <
>>>>>>> eelco.dolstra@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-carrie=
r
>>>>>>>> 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-dev@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=C5=BC
>>
>
[Attachment #5 (text/html)]
<div dir="ltr"><div>We could close all >1 month old issues as a one-time thing but \
first we really should have a proper process in place.<br><br></div><div>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.<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, 22 \
Jul 2016 at 13:25 Wout Mertens <<a \
href="mailto:wout.mertens@gmail.com">wout.mertens@gmail.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">> <span \
style="color:rgb(33,33,33);font-family:"helvetica \
neue",helvetica,arial,sans-serif">One day I closed an issue because nobody cared \
for months (even I didn't </span><span \
style="color:rgb(33,33,33);font-family:"helvetica \
neue",helvetica,arial,sans-serif;line-height:1.5">care enough even though I \
reported it). Someone reopened it saying </span><span \
style="color:rgb(33,33,33);font-family:"helvetica \
neue",helvetica,arial,sans-serif;line-height:1.5">that </span><span \
style="line-height:1.5">a </span><span \
style="line-height:1.5;color:rgb(33,33,33);font-family:"helvetica \
neue",helvetica,arial,sans-serif">lack of care was not a reason to close an \
issue and someone else fixed </span><span \
style="color:rgb(33,33,33);font-family:"helvetica \
neue",helvetica,arial,sans-serif;line-height:1.5">the issue the same day. So, \
closing can even encourage fixing :-).</span><div><span \
style="color:rgb(33,33,33);font-family:"helvetica \
neue",helvetica,arial,sans-serif;line-height:1.5"><br></span></div><div><span \
style="color:rgb(33,33,33);font-family:"helvetica \
neue",helvetica,arial,sans-serif;line-height:1.5">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.</span></div><div><span style="color:rgb(33,33,33);font-family:"helvetica \
neue",helvetica,arial,sans-serif;line-height:1.5"><br></span></div><div><font \
color="#212121" face="helvetica neue, helvetica, arial, sans-serif">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.</font></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jul \
22, 2016 at 2:20 PM Tomasz Czyż <<a href="mailto:tomasz.czyz@gmail.com" \
target="_blank">tomasz.czyz@gmail.com</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"><a \
href="https://github.com/kubernetes/kubernetes" \
target="_blank">https://github.com/kubernetes/kubernetes</a> - just adding as \
reference :-)<br><div><br></div></div><div class="gmail_extra"></div><div \
class="gmail_extra"><br><div class="gmail_quote">2016-07-22 12:07 GMT+01:00 zimbatm \
<span dir="ltr"><<a href="mailto:zimbatm@zimbatm.com" \
target="_blank">zimbatm@zimbatm.com</a>></span>:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"><div>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!<br><br>Here are a couple of aspects that I think are part of \
the problem:<br><br>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.<br><br>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.<br><br></div><div>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.<br><br></div><div>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.<br><br></div><div>Hmm \
that's it for now ^_^<br></div><div><br><br></div></div><div><div><br><div \
class="gmail_quote"><div dir="ltr">On Fri, 22 Jul 2016 at 11:04 Domen Kožar <<a \
href="mailto:domen@dev.si" target="_blank">domen@dev.si</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">The real question is \
how to organize so that we triage all incoming issues. Closing them is the easy part \
:)</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 22, 2016 at \
11:52 AM, Wout Mertens <span dir="ltr"><<a href="mailto:wout.mertens@gmail.com" \
target="_blank">wout.mertens@gmail.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr">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.</div><div><div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jul \
22, 2016 at 11:49 AM Roger Qiu <<a href="mailto:roger.qiu@matrix.ai" \
target="_blank">roger.qiu@matrix.ai</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<p>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.<br>
</p></div><div bgcolor="#FFFFFF" text="#000000">
<br>
<div>On 22/07/2016 7:37 PM, Wout Mertens
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">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.
<div><span style="line-height:1.5"><br>
</span></div>
<div><span style="line-height:1.5">All the *real* issues will
stay active, since people will reopen them. All the rest
will be available in the history.</span></div>
<div><span style="line-height:1.5"><br>
</span></div>
<div><span style="line-height:1.5">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.</span></div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Fri, Jul 22, 2016 at 11:17 AM Oliver Charles
<<a href="mailto:ollie@ocharles.org.uk" \
target="_blank">ollie@ocharles.org.uk</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <div dir="ltr">Agreed.
<div><br>
</div>
<div>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.</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Fri, Jul 22, 2016 at 10:15 AM Eelco
Dolstra <<a href="mailto:eelco.dolstra@logicblox.com" \
target="_blank">eelco.dolstra@logicblox.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex">Hi,<br> <br>
On 07/22/2016 09:06 AM, Wout Mertens wrote:<br>
<br>
> We have 1238 open issues and 286 open PRs.<br>
><br>
> That is just too much to reason about.<br>
><br>
> How about using something like <a \
href="https://github.com/twbs/no-carrier" rel="noreferrer" \
target="_blank">https://github.com/twbs/no-carrier</a> which<br>
> auto-closes after 14 days of inactivity, and reopens
on a new comment?<br>
<br>
There is something to be said for auto-closing issues
after a long time (e.g.<br>
Fedora auto-closes inactive issues from CURRENT-2 releases
ago), but 14 days is<br>
waaaay to short. Bugs don't disappear after 14 days...<br>
<br>
--<br>
Eelco Dolstra | LogicBlox, Inc. | <a href="http://nixos.org/%7Eeelco/" \
rel="noreferrer" target="_blank">http://nixos.org/~eelco/</a><br> \
_______________________________________________<br> nix-dev mailing list<br>
<a href="mailto:nix-dev@lists.science.uu.nl" \
target="_blank">nix-dev@lists.science.uu.nl</a><br> <a \
href="http://lists.science.uu.nl/mailman/listinfo/nix-dev" rel="noreferrer" \
target="_blank">http://lists.science.uu.nl/mailman/listinfo/nix-dev</a><br> \
</blockquote> </div>
_______________________________________________<br>
nix-dev mailing list<br>
<a href="mailto:nix-dev@lists.science.uu.nl" \
target="_blank">nix-dev@lists.science.uu.nl</a><br>
<a href="http://lists.science.uu.nl/mailman/listinfo/nix-dev" \
rel="noreferrer" target="_blank">http://lists.science.uu.nl/mailman/listinfo/nix-dev</a><br>
</blockquote>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
nix-dev mailing list
<a href="mailto:nix-dev@lists.science.uu.nl" \
target="_blank">nix-dev@lists.science.uu.nl</a> <a \
href="http://lists.science.uu.nl/mailman/listinfo/nix-dev" \
target="_blank">http://lists.science.uu.nl/mailman/listinfo/nix-dev</a> </pre>
</blockquote>
<br>
</div><div bgcolor="#FFFFFF" text="#000000"><pre cols="72">--
Founder of Matrix AI
<a href="https://matrix.ai/" target="_blank">https://matrix.ai/</a>
<a href="tel:%2B61420925975" value="+61420925975" \
target="_blank">+61420925975</a></pre> </div>
_______________________________________________<br>
nix-dev mailing list<br>
<a href="mailto:nix-dev@lists.science.uu.nl" \
target="_blank">nix-dev@lists.science.uu.nl</a><br> <a \
href="http://lists.science.uu.nl/mailman/listinfo/nix-dev" rel="noreferrer" \
target="_blank">http://lists.science.uu.nl/mailman/listinfo/nix-dev</a><br> \
</blockquote></div> </div></div><br>_______________________________________________<br>
nix-dev mailing list<br>
<a href="mailto:nix-dev@lists.science.uu.nl" \
target="_blank">nix-dev@lists.science.uu.nl</a><br> <a \
href="http://lists.science.uu.nl/mailman/listinfo/nix-dev" rel="noreferrer" \
target="_blank">http://lists.science.uu.nl/mailman/listinfo/nix-dev</a><br> \
<br></blockquote></div><br></div> _______________________________________________<br>
nix-dev mailing list<br>
<a href="mailto:nix-dev@lists.science.uu.nl" \
target="_blank">nix-dev@lists.science.uu.nl</a><br> <a \
href="http://lists.science.uu.nl/mailman/listinfo/nix-dev" rel="noreferrer" \
target="_blank">http://lists.science.uu.nl/mailman/listinfo/nix-dev</a><br> \
</blockquote></div> </div></div><br>_______________________________________________<br>
nix-dev mailing list<br>
<a href="mailto:nix-dev@lists.science.uu.nl" \
target="_blank">nix-dev@lists.science.uu.nl</a><br> <a \
href="http://lists.science.uu.nl/mailman/listinfo/nix-dev" rel="noreferrer" \
target="_blank">http://lists.science.uu.nl/mailman/listinfo/nix-dev</a><br> \
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br></div><div \
class="gmail_extra"><div data-smartmail="gmail_signature">Tomasz Czyż</div> \
</div></blockquote></div> </blockquote></div>
_______________________________________________
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic