[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 <wout.mertens at gmail.com> 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
> <http://rfc.zeromq.org/spec:42/C4/#23-patch-requirements> 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 <kevincox at kevincox.ca> 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 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/11c92c61/attachment.html>