Re: [Nix-dev] Too many open issues

[Kevin Cox]

On 26/07/16 16:22, Wout Mertens wrote:
> Ok fair enough, so no auto-closing but a 6 month reminder would be good.
> 

The previously mentioned bot had the option to only close when a given
label was applied. I think this would be beneficial as a "need-info"
label could be applied and if the OP isn't still interested it could be
closed.



signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[stewart mackenzie]

On 26 Jul 2016 22:22, "Wout Mertens"  wrote:
> Anybody up for C4?

Finally some sanity! Yes! (FFS!)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Wout Mertens]

Ok fair enough, so no auto-closing but a 6 month reminder would be good.

Anybody up for C4?

On Tue, Jul 26, 2016, 9:18 PM Vladimír Čunát  wrote:

> On 07/24/2016 01:32 PM, Matthias Beyer wrote:
> > As far as I remember, this was over a year ago and they told me
> > (again, AFAIR) they already have something like that on their list.
>
> I reported one thing or two to github, and they replied *very* promptly
> and politely, but nothing real has ever happened in the following months...
>
> BTW, I also don't thing auto-closing would really help. It seems
> unavoidable that a large distribution does have thousands of unsolved
> issues. If you compare to the number of binary builds we provide, it's
> not really that many.
>
> --Vladimir
>
>
> ___
> 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

Re: [Nix-dev] Too many open issues

[Vladimír Čunát]

On 07/24/2016 01:32 PM, Matthias Beyer wrote:
> As far as I remember, this was over a year ago and they told me 
> (again, AFAIR) they already have something like that on their list.

I reported one thing or two to github, and they replied *very* promptly
and politely, but nothing real has ever happened in the following months...

BTW, I also don't thing auto-closing would really help. It seems
unavoidable that a large distribution does have thousands of unsolved
issues. If you compare to the number of binary builds we provide, it's
not really that many.

--Vladimir




smime.p7s
Description: S/MIME Cryptographic Signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Tomasz Czyż]

Profpatsch, nice job, thanks.

2016-07-25 12:41 GMT+01:00 Profpatsch :

> On 16-07-24 03:12pm, Arnold Krille wrote:
> > FULL ACK!
> >
> > I couldn't said it any better.
> >
> > And please never, ever think about closing users contribution without
> > looking at them at least once by a human!
>
> +1
>
> Having done a lot of triaging these past days there were (estimated)
>
> 30% issues that had been solved and forgotten
> 30% issues that still need to be solved
> 20% issues that were not relevant anymore
> 10% issues where reminding lead to instant PRs
> 10% systemic issues
>
> Apart of the first 30% I think auto-closing would do
> more harm than good.
> For a lot of stuff a simple reminder after ~6 months can do wonders,
> simply because people learned new things in the meantime and can
> use them to solve the problem.
>
>
> --
> Proudly written in Mutt with Vim on NixOS.
> Q: Why is this email five sentences or less?
> A: http://five.sentenc.es
> May take up to five days to read your message. If it’s urgent, call me.
>
> ___
> 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

Re: [Nix-dev] Too many open issues

[Profpatsch]

On 16-07-24 03:12pm, Arnold Krille wrote:
> FULL ACK!
> 
> I couldn't said it any better.
> 
> And please never, ever think about closing users contribution without
> looking at them at least once by a human!

+1

Having done a lot of triaging these past days there were (estimated)

30% issues that had been solved and forgotten
30% issues that still need to be solved
20% issues that were not relevant anymore
10% issues where reminding lead to instant PRs
10% systemic issues

Apart of the first 30% I think auto-closing would do
more harm than good.
For a lot of stuff a simple reminder after ~6 months can do wonders,
simply because people learned new things in the meantime and can
use them to solve the problem.


-- 
Proudly written in Mutt with Vim on NixOS.
Q: Why is this email five sentences or less?
A: http://five.sentenc.es
May take up to five days to read your message. If it’s urgent, call me.


signature.asc
Description: PGP signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Kevin Cox]

On Jul 23, 2016 08:23, "obadz"  wrote:
>
> On Sat, Jul 23, 2016 at 2:19 AM, Benno Fünfstück <
benno.fuenfstu...@gmail.com> wrote:
>>>
>>> The key here would be that we shouldn't get rattled if we get assigned
an issue/PR. All it means is "I think you know more about this than I do,
feel free to pass it on to someone else if aren't the right person or can't
handle this with the appropriate urgency".
>>
>>
>> I don't think that assignment is the right tool for this job. Assignment
in my opinion should be used for the purpose of avoiding duplicated work:
you assign yourself to an issue if you plan on working on it, so that
everyone else knows that they shouldn't work on that particular task
themselves.
>
>
> Fully agree that the purpose of assignment is to avoid duplicated work.
That is why I think the first person to ever review an issue (maybe that's
mentionbot) should assign someone to that issue. Once that's done, this
issue won't waste anyone's else's time until the current assignee decides
who would be a better assignee. This means the amount of reviewing work
done is about O(n_issues).
>

The nice thing about assignment is it is a little harder for things to get
lost. And I think asking the current assignee "I have time to take this
over, is that OK?" is an awesome question to ask if it appears that nothing
is being done.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Roland Koebler]

Hi,

as a Nix user: I think that it's a *very* *very* bad idea to auto-close
issues after 14 days. Usually, if I find a bug, I report it. If my
bugreport then gets auto-closed after a few days/weeks, it would feel like 
(a) the maintainers simply don't care about bugs (and prefer to ignore
bugs rather than fixing them), and
(b) that bugreports are undesirable.

> All the *real* issues will stay active, since people will reopen them.
No.
As a "normal user", I probably wouldn't ever reopen a bug.
("I have submitted a bug; if it was closed, the maintainers probably
solved it or closed it for a good reason.", or
"I have submitted a bug. Why should I tell them 14 days later that the
bug still exists? Do they think bugs magically disappear? WTF?")

As a more experienced user, I *might* re-open it once, but when it's
auto-closed again, I would be very annoyed, wouldn't report any more
bugs (since obviously the maintainers don't care), and probably go
away (since obviously the maintainers don't care about bugs; and I
don't want to use software where the maintainers don't care about
bugs). This is NOT, what NixOS needs (at least in my opinion).

In my opinion, auto-closing would be ok for:
- bugs which cannot be reproduced easily and need more information,
  but the submitter does not submit this information, and
- bugs about packages which are no longer in Nix

All other bugreport-handling-problems should be solved by filtering,
searching or tagging bugreports, but not by (auto-)closing them.


just my 0.02ct
Roland
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[obadz]

On Sat, Jul 23, 2016 at 2:19 AM, Benno Fünfstück <
benno.fuenfstu...@gmail.com> wrote:

> The key here would be that we shouldn't get rattled if we get assigned an
>> issue/PR. All it means is "I think you know more about this than I do, feel
>> free to pass it on to someone else if aren't the right person or can't
>> handle this with the appropriate urgency".
>>
>
> I don't think that assignment is the right tool for this job. Assignment
> in my opinion should be used for the purpose of avoiding duplicated work:
> you assign yourself to an issue if you plan on working on it, so that
> everyone else knows that they shouldn't work on that particular task
> themselves.
>

Fully agree that the purpose of assignment is to avoid duplicated work.
That is why I think the first person to ever review an issue (maybe that's
mentionbot) should assign someone to that issue. Once that's done, this
issue won't waste anyone's else's time until the current assignee decides
who would be a better assignee. This means the amount of reviewing work
done is about O(n_issues).

The alternative is for all of us to troll through every issue and of course
decide that most of them aren't things we are best positioned to resolve.
That's O(n_issues * n_reviewers).
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Wout Mertens]

   - *Splitting the repo*: Indeed, losing history is bad, so no go. See
   below for alternative.
   - *Triage*: Good ideas to split the load. See below.
   - *Autoclose*: Still convinced we should use it. See below.

For *triage*, we can indeed triage by section (just add labels) and then
maintainers can filter by the labels they can work on.
Right now we have 515 issues without labels
.
*Let's label them!*
We *need to make labels based on skillset* needed to fix. The topic labels
come close, but e.g. "topic: non-nixos" is not a skillset. "skill: bash"
and "skill: kernel" are. Labels are free, let's add all the ones that can
be useful for filtering.

*Splitting the repo* is not a good idea. However, some PRs are languishing
because it is unclear if they can be merged, and the persons that can make
the call are unresponsive. Using the C4 rules
, it is very *clear
when a PR can be merged*, and what needs to be done to make it mergeable.
Instead of splitting the repo, let's mark certain parts of the code as
"merge only when permission from core maintainers", and all the rest is
open for C4.

*Autoclosing* is like garbage collection. Auto-close and then reopening by
a response, is more efficient than triagers having to go in and decide if
something can be closed. We can add labels that prevent auto-close.
No warnings are needed btw, since responding reopens. A warning means two
mails instead of one.
*We should not be afraid of missing out on bugs or ideas*. They are
re-discovered all the time, and the good ones will be interesting enough to
stay open.

So, conclusion:

   1. We need to add *skillset labels*
   2. We need a *triager army* that apply labels to unlabeled issues
   3. *Maintainers use filters* to see their custom issue list
   4. Let's use C4 
   to *objectively decide mergeability*
   5. Let's run autoclose, starting with issues not updated for 6 months (205
   of them
   

   )

I'll start a different email thread soliciting for skillset labels.

On Sat, Jul 23, 2016 at 3:22 AM Profpatsch  wrote:

> On 16-07-22 09:59am, Michael Walker wrote:
> > If there are 1000+ open issues, it's hard to know what to prioritise.
> > If inactive issues get closed, it at least helps cut down on things
> > which may no longer be relevant (and if they are, someone finds the
> > closed issue, comments in it, and it opens again).
>
> I do think Github gives us the means for that.
> You can sort by activity, by age, by label, by reactions …
>
> To start triaging just sort by least recently updated
> and work from start to finish. ;)
>
> --
> Proudly written in Mutt with Vim on NixOS.
> Q: Why is this email five sentences or less?
> A: http://five.sentenc.es
> May take up to five days to read your message. If it’s urgent, call me.
> ___
> 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

Re: [Nix-dev] Too many open issues

[Profpatsch]

On 16-07-22 09:59am, Michael Walker wrote:
> If there are 1000+ open issues, it's hard to know what to prioritise.
> If inactive issues get closed, it at least helps cut down on things
> which may no longer be relevant (and if they are, someone finds the
> closed issue, comments in it, and it opens again).

I do think Github gives us the means for that.
You can sort by activity, by age, by label, by reactions …

To start triaging just sort by least recently updated
and work from start to finish. ;)

-- 
Proudly written in Mutt with Vim on NixOS.
Q: Why is this email five sentences or less?
A: http://five.sentenc.es
May take up to five days to read your message. If it’s urgent, call me.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Benno Fünfstück]

> The key here would be that we shouldn't get rattled if we get assigned an
> issue/PR. All it means is "I think you know more about this than I do, feel
> free to pass it on to someone else if aren't the right person or can't
> handle this with the appropriate urgency".
>

I don't think that assignment is the right tool for this job. Assignment in
my opinion should be used for the purpose of avoiding duplicated work: you
assign yourself to an issue if you plan on working on it, so that everyone
else knows that they shouldn't work on that particular task themselves.

An alternative approach is to just ping the relevant persons in the issue.
This way, they'll get notifications on updates to the issue. But I think
this partly already happens right now through mentionbot.

What I would like to see, however, is a clear set of guidelines that list a
person who has the final say over changes in each subset of nixpkgs. It is
not uncommon for PRs to stay around for months because it is unclear who
may approve/disapprove them (and saying no to PRs sometimes is important as
well). For example, this guideline could list someone responsible for each
language currently supported by nixpkgs (python, haskell, etc) or for parts
of the nixos module system or for the stdenv and so on.

Just my two cents,
Benno

>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[obadz]

On Fri, Jul 22, 2016 at 6:21 PM, Guillaume Maudoux (Layus) <
layus...@gmail.com> wrote:

> Furthermore, I think that every issue should be assigned to someone. Being
> assigned to an issue would mean that you are responsible for its progress,
> like pinging the maintainers, not for fixing the problem by yourself (but
> you still can).
>

I think this is a key point. While we can't really hope for 0 open
issues/PR, maybe we should be striving towards 0 unassigned issues/PR.

May I suggest a policy where we "liberally" assign issues/PR to each other.
The lifecycle of an issue/PR would then look something like this:

   - First triager comes up with his best guess as to who could be useful
   on the issue/PR, maybe based on `git log`
   - First assignee may decide that he isn't the best person to look at
   this and reassigns further
   - Hopefully the iterative process lets assignment converge towards the
   right expert

Of course the downside of such a process is that major contributors whose
time is already stretched thin are going to end up with a
disproportionately high share of issues/PRs assigned to them. However they
are also most likely to know who is capable of tackling the issue/PR and
further re-assign it, or to request help by adding a tag like `status:
need-help`?

The key here would be that we shouldn't get rattled if we get assigned an
issue/PR. All it means is "I think you know more about this than I do, feel
free to pass it on to someone else if aren't the right person or can't
handle this with the appropriate urgency".

Thoughts?
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Guillaume Maudoux (Layus)]

Hi,

May I suggest that the culprit is the tool itself ? Clearly GitHub does a poor 
job at managing and displaying issues. It works well for pull requests and code 
exploration, but not for issues.

What we need is to maintain a pool of issues that need attention. Ideally this 
pool is quite small (max 20), and contains issues that require some action, or 
could benefit from anyone's input.

For example, a new issue requires attention. When the discussion has started, 
it can be removed from the pool.
Issues with no activity also require attention eventually.

Furthermore, I think that every issue should be assigned to someone. Being 
assigned to an issue would mean that you are responsible for its progress, like 
pinging the maintainers, not for fixing the problem by yourself (but you still 
can).

We really need a way to get a short list of items requiring global attention, 
then triage/dispatch it elsewhere to keep focus on interesting things.
If GitHub cannot do that, we may need another tool.

Regards,

-- Layus.___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Azul]

triage exists to help manipulating a backlog, it is just another tool to
make sure team members are only working valuable issues and not spend the
time bikshedding, it also prevents duplication.
auto-closing issues due to being no longer applicable, or simply to reduce
the size of the backlog is another tool.
theming or (tagging) issues another process that helps to keep team members
with knowhow in a particular area aligned with the issues they care or are
able to fix in the shortest amount of time compared to other
dev/maintainers in the team.
voting is another good way to measure how important an issue is for a
number of users.
with these processes in place, someone responsible for managing the backlog
can look to every issue opened and work their way to reduce the overall
size of that backlog. then, it can be tagged and grouped into themes,
languages, maintainers, expertise and so on so that maintainers can find
then quickly.
if the backlog is then sorted by votes, common sense or other means then it
can be sliced and batched so that there is always a chunk of issues
available to be worked on ( attempt readers probably noticed by now I am a
kanban boy).

open source prj on github have the best tooling available to manage these
workflows, tools like the 'autoclose machine' mentioned here, zenhub for
managing work in progress in a simple board and others  are out there and
usually free for open source projects.

from this thread it seems to me that the most useful action would be to
nominate someone to manage that backlog and make a constant effort to bring
it down to a workable size, and always ordered by the ones that need to be
tackled first.
On 22 Jul 2016 17:58, "Guillaume Maudoux (Layus)" 
wrote:

> Hi,
>
> I have tried code triage for some weeks, and finally stopped using it.
>
> Yes, it allows to spread attention to many issues, but many issues do not
> need attention, either because they are already in progress, or because
> nobody really cares.
>
> Some issues are even weirder, like the 200 issues opened automatically for
> wiki migration. These are the only one that could benefit from auto close.
>
> Codetriage is not the solution, and not really a solution.
>
> Regards,
>
> -- Layus.
>
> Le 22 juillet 2016 20:12:18 UTC+07:00, Kevin Cox  a
> écrit :
>>
>> On 22/07/16 08:55, Alexey Shmalko wrote:
>>
>>>  This one: https://www.codetriage.com/nixos/nixpkgs
>>
>>
>>
>> That's it! I have subscribed to get a couple issues a day so hopefully I
>> can help a bit. This site seems like a nice way to spread the load.
>>
>> It's open source too, and I just opened an issue asking them to
>> implement filters as I'm not really interesting in seeing in-progress
>> issues.
>>
>> https://github.com/codetriage/codetriage/issues/498
>>
>>
>> --
>>
>> 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

Re: [Nix-dev] Too many open issues

[Guillaume Maudoux (Layus)]

Hi,

I have tried code triage for some weeks, and finally stopped using it.

Yes, it allows to spread attention to many issues, but many issues do not need 
attention, either because they are already in progress, or because nobody 
really cares.

Some issues are even weirder, like the 200 issues opened automatically for wiki 
migration. These are the only one that could benefit from auto close.

Codetriage is not the solution, and not really a solution.

Regards,

-- Layus.

Le 22 juillet 2016 20:12:18 UTC+07:00, Kevin Cox  a écrit 
:
>On 22/07/16 08:55, Alexey Shmalko wrote:
>> This one: https://www.codetriage.com/nixos/nixpkgs
>>
>
>That's it! I have subscribed to get a couple issues a day so hopefully
>I
>can help a bit. This site seems like a nice way to spread the load.
>
>It's open source too, and I just opened an issue asking them to
>implement filters as I'm not really interesting in seeing in-progress
>issues.
>
>https://github.com/codetriage/codetriage/issues/498
>
>
>
>
>
>
>___
>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

Re: [Nix-dev] Too many open issues

[Paul Dufresne]

I did triaging in the past in a big distro.
What was frustrating was that I had the feeling that most bugs were
fixed by themselves (like if they were
rediscovered and fix upstream, or care about when developers
encounters them by themselves).

Thinking about it, I have come to the conclusion that it is probably
part of how teams organize like:
-documenters
-bug triagers
-developers
etc.

I think it would help to organize around subject:
-administrating tools
--cloud
--other
-games
-desktops
--kde
--gnome-shell
--mate
--cinnamon
--other
-printing
-audio/video
-office software
-science
--astronomy
--medical
--electronic
--other
-other

Developers are likely to prefer to organize around programming languages.
I guess it is ok to let them aggregate by programming language, but
that way, should be
kept less important than the previous category I think.

So it is important that bug triagers, documentation, etc. are on the
same teams as developers that have
access to infrastructure, and that suggestions can become real changes.

I believe that to achieve this, a forum is a much better place than a
mailing list.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Matthias Beyer]

On 22-07-2016 13:26:13, Wout Mertens wrote:
> Ok, how about this: We split nixpkgs in nixpkgs-core and nixpkgs-community

I would argue against this.

As others have explained (and as Graham Christensen wrote in the next 
mail in this thread) size is not a bad thing and we really should be 
proud.

Reaching out to others and asking how they do it is way better IMO.
Splitting the problem into smaller ones will not solve the issue.

Also: "Moving" packages between repositories is not as trivial as you 
might think. We would lose history _all the time_, and at least I 
consider this a big NO-NO.

-- 
Mit freundlichen Grüßen,
Kind regards,
Matthias Beyer

Proudly sent with mutt.
Happily signed with gnupg.


signature.asc
Description: PGP signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Matthias Beyer]

On 22-07-2016 12:25:25, Wout Mertens wrote:
> 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.

This is a neat idea IMHO.

--
Mit freundlichen Grüßen,
Kind regards,
Matthias Beyer

Proudly sent with mutt.
Happily signed with gnupg.


signature.asc
Description: PGP signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Matthias Beyer]

On 22-07-2016 14:18:55, Damien Cassou wrote:
> Wout Mertens  writes:
> 
> > 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?
> 
> I agree with you about auto-closing old issues but I think 14 days is
> way too short. For me, an issue must be automatically closed
> 
> - if nobody cares enough to say either that he is impacted too or is
>   still impacted
> 
> - if nobody cares enough to fix the issue
> 
> There is not enough man power for nixpkgs to be bug free. Automatically
> closing issues means open issues are the ones people care about.
> Moreover, the tools auto-closing issues must warn a few days before
> closing the issue to raise awareness of the open issues.
> 
> 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
> 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 :-).
> 

I agree with you. I wouldn't draw the line at 14 days, it is way to 
short. We have sometimes unstable beeing not updated for up to 4 
weeks... and I guess that should also be the line. let it be 28 days, 
reporting after 25 days that the issue will be closed and another 3 
until it is closed, maybe.

-- 
Mit freundlichen Grüßen,
Kind regards,
Matthias Beyer

Proudly sent with mutt.
Happily signed with gnupg.


signature.asc
Description: PGP signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Graham Christensen]

I see the growth in contributions and PRs as a great indicator of a healthy
project.

We get around 1,000 new issues/PRs every 1.5 months. The 33 PRs from the
last ~24 hours were contributed by 24 different people[0]. Our issuestats
badges say we close PRs in about 18 hours, and issues in 5 days.

Those are pretty good numbers, I think.

Here are some other projects and numbers:

 - Docker has 1,800 open issues, 142 open PRs
 - Ruby on Rails has 477 open issues, 632 open PRs

Here are some other _distributions_:

 - Debian has 90,000 bugs (?) https://www.debian.org/Bugs/
 - Redhat has 25,000 bugs
 - Gentoo has 20,000 bugs

I think we should be really proud of the number of quality contributions[1]
we get, and how effectively and promptly we can merge so many of them.

Some opinions:

 - I think we should be seeking out information about how other large,
popular open source projects deal with issue and PR load. I've reached out
to people at Docker, Drupal, and Emacs for feedback.
 - I think auto-closing issues which don't get attention is
passive-aggressive. I would be more amenable to a process of tagging issues
as "Needs response from submitter" and auto-closing if that isn't resolved.
Docker has/had a bot to let users add labels to issues.
 - I think splitting the repository isn't going to do us any favors and
just moves the burden around, and raises the difficulty of submitting
issues and updates. I don't think making it more difficult is in our best
interest.

Best,
Graham Christensen

[0]: This is amazing! No small group is submitting the bulk of the PRs.
Contributors:
https://gist.github.com/grahamc/cff852defb726dd5ae64b5a3287651d4
[1]: https://github.com/docker/docker/pulls?q=is%3Apr+is%3Aclosed


On Fri, Jul 22, 2016 at 8:26 AM Wout Mertens  wrote:

> Ok, how about this: We split nixpkgs in nixpkgs-core and nixpkgs-community
>
> For any package or service, there need to be at least 3 active
> maintainers, or it goes out of nixpkgs-core into a nixpkgs-community repo.
>
> Hydra builds nixos from nixpkgs-core, and nixpkgs from both combined.
>
> nixpgks-core issues are mostly solved by the maintainers or of course any
> PR that is good enough.
>
> In the nixpkgs-community we implement the
> http://rfc.zeromq.org/spec:42/C4/ process, meaning that any PR that
> fulfills all the objective goals gets merged. It worked well for ZeroMQ,
> and takes the guesswork out of PRs. Tree maintainers only need to evaluate
> the C4 objectives
>  of the PR, and
> if they are fulfilled, merge.
>
> Packages get moved between the two repos as support status changes.
>
> That way, we have a small "trust base" for server systems, and a large
> "community base" for the latest and greatest. NixOS is so flexible that you
> can mix and match as you wish.
>
> On Fri, Jul 22, 2016 at 3:12 PM Kevin Cox  wrote:
>
>> On 22/07/16 08:55, Alexey Shmalko wrote:
>> > This one: https://www.codetriage.com/nixos/nixpkgs
>> >
>>
>> That's it! I have subscribed to get a couple issues a day so hopefully I
>> can help a bit. This site seems like a nice way to spread the load.
>>
>> It's open source too, and I just opened an issue asking them to
>> implement filters as I'm not really interesting in seeing in-progress
>> issues.
>>
>> https://github.com/codetriage/codetriage/issues/498
>>
>>
>> ___
>> 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

Re: [Nix-dev] Too many open issues

[Wout Mertens]

Ok, how about this: We split nixpkgs in nixpkgs-core and nixpkgs-community

For any package or service, there need to be at least 3 active maintainers,
or it goes out of nixpkgs-core into a nixpkgs-community repo.

Hydra builds nixos from nixpkgs-core, and nixpkgs from both combined.

nixpgks-core issues are mostly solved by the maintainers or of course any
PR that is good enough.

In the nixpkgs-community we implement the
http://rfc.zeromq.org/spec:42/C4/ process,
meaning that any PR that fulfills all the objective goals gets merged. It
worked well for ZeroMQ, and takes the guesswork out of PRs. Tree
maintainers only need to evaluate the C4 objectives
 of the PR, and if
they are fulfilled, merge.

Packages get moved between the two repos as support status changes.

That way, we have a small "trust base" for server systems, and a large
"community base" for the latest and greatest. NixOS is so flexible that you
can mix and match as you wish.

On Fri, Jul 22, 2016 at 3:12 PM Kevin Cox  wrote:

> On 22/07/16 08:55, Alexey Shmalko wrote:
> > This one: https://www.codetriage.com/nixos/nixpkgs
> >
>
> That's it! I have subscribed to get a couple issues a day so hopefully I
> can help a bit. This site seems like a nice way to spread the load.
>
> It's open source too, and I just opened an issue asking them to
> implement filters as I'm not really interesting in seeing in-progress
> issues.
>
> https://github.com/codetriage/codetriage/issues/498
>
>
> ___
> 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

Re: [Nix-dev] Too many open issues

[Kevin Cox]

On 22/07/16 08:55, Alexey Shmalko wrote:
> This one: https://www.codetriage.com/nixos/nixpkgs
>

That's it! I have subscribed to get a couple issues a day so hopefully I
can help a bit. This site seems like a nice way to spread the load.

It's open source too, and I just opened an issue asking them to
implement filters as I'm not really interesting in seeing in-progress
issues.

https://github.com/codetriage/codetriage/issues/498




signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[zimbatm]

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  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ż  wrote:
>
>> https://github.com/kubernetes/kubernetes - just adding as reference :-)
>>
>>
>> 2016-07-22 12:07 GMT+01:00 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  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 
 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 
> 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 <
>>> 

Re: [Nix-dev] Too many open issues

[Alexey Shmalko]

This one: https://www.codetriage.com/nixos/nixpkgs

On 07/22/2016 03:30 PM, Kevin Cox wrote:
> I'm not a huge fan of auto-closing issues based on just activity. The one 
> auto-close feature I do like is the `need info` tag when you need more from 
> the reporter. Then the issue is closed in a week or two if they don't respond.
> 
> The reason I don't like auto-closing issues is that it seems more like 
> fighting the symptom then the problem. Just because you close an issue 
> doesn't mean that it doesn't exist. I think a better way is to get more 
> triager to quickly put issues on the wishlist or find an assignee. Rather 
> then close it is probably better to have an "important" or tag of things that 
> should be looked at first (and maybe try to keep that close to zero). I see 
> little value to closing issues just because we don't want to work on them 
> right now.
> 
> It is really painful that only commiters can add tags because I would love to 
> help out with triaging more then just commenting (I think comments often have 
> low value because you can't filter on them).
> 
> One other thing that might help is I remember a service that would send a 
> couple of open issues to your inbox to help divide the load of triaging. I'm 
> going to see if I can find it again as it would probably be useful.
> 
> 
> 
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
> 



signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Kevin Cox]

I'm not a huge fan of auto-closing issues based on just activity. The one
auto-close feature I do like is the `need info` tag when you need more from
the reporter. Then the issue is closed in a week or two if they don't
respond.

The reason I don't like auto-closing issues is that it seems more like
fighting the symptom then the problem. Just because you close an issue
doesn't mean that it doesn't exist. I think a better way is to get more
triager to quickly put issues on the wishlist or find an assignee. Rather
then close it is probably better to have an "important" or tag of things
that should be looked at first (and maybe try to keep that close to zero).
I see little value to closing issues just because we don't want to work on
them right now.

It is really painful that only commiters can add tags because I would love
to help out with triaging more then just commenting (I think comments often
have low value because you can't filter on them).

One other thing that might help is I remember a service that would send a
couple of open issues to your inbox to help divide the load of triaging.
I'm going to see if I can find it again as it would probably be useful.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Tomasz Czyż]

https://github.com/kubernetes/kubernetes - just adding as reference :-)


2016-07-22 12:07 GMT+01:00 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  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 
>> 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  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 
 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
>> wy 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
 

Re: [Nix-dev] Too many open issues

[Damien Cassou]

Wout Mertens  writes:

> 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?

I agree with you about auto-closing old issues but I think 14 days is
way too short. For me, an issue must be automatically closed

- if nobody cares enough to say either that he is impacted too or is
  still impacted

- if nobody cares enough to fix the issue

There is not enough man power for nixpkgs to be bug free. Automatically
closing issues means open issues are the ones people care about.
Moreover, the tools auto-closing issues must warn a few days before
closing the issue to raise awareness of the open issues.

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
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 :-).

Best,

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [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  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 
> 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  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 
>>> 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
> wy 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
> 

Re: [Nix-dev] Too many open issues

[Domen Kožar]

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 
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  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 
>> 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
 wy 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

Re: [Nix-dev] Too many open issues

[Wout Mertens]

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  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 
> 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
>>> wy 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

Re: [Nix-dev] Too many open issues

[Roger Qiu]

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 > 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
>
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
wy 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 list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


--
Founder of Matrix AI
https://matrix.ai/
+61420925975

___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Wout Mertens]

To give you an idea, there are still 109 issues that were updated in the
last 2 weeks:
https://github.com/NixOS/nixpkgs/issues?utf8=%E2%9C%93=is%3Aissue%20is%3Aopen%20%20updated%3A%3E%3D2016-07-08

This is already quite enough to work on.

On Fri, Jul 22, 2016 at 11:37 AM 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 
> 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
>>> wy 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 list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Wout Mertens]

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 
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
>> wy 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 list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Oliver Charles]

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 
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
> wy 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

Re: [Nix-dev] Too many open issues

[Michael Walker]

If there are 1000+ open issues, it's hard to know what to prioritise.
If inactive issues get closed, it at least helps cut down on things
which may no longer be relevant (and if they are, someone finds the
closed issue, comments in it, and it opens again).

On 22 July 2016 at 09:57, Oliver Charles  wrote:
> What does the number 0 bring us if there are in reality still hundreds of
> issues?
>
>
> On Fri, 22 Jul 2016, 8:06 a.m. 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?
>>
>> I'm sure that if we have close to 0 open issues/PRs, there will be a
>> greater incentive to bring that number to 0…
>> ___
>> 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
>



-- 
Michael Walker (http://www.barrucadu.co.uk)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Oliver Charles]

What does the number 0 bring us if there are in reality still hundreds of
issues?

On Fri, 22 Jul 2016, 8:06 a.m. 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?
>
> I'm sure that if we have close to 0 open issues/PRs, there will be a
> greater incentive to bring that number to 0…
> ___
> 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] Too many open issues

[Wout Mertens]

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?

I'm sure that if we have close to 0 open issues/PRs, there will be a
greater incentive to bring that number to 0…
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev