[Nix-dev] Some bug tracker experience and RFC on improvements

[Vladimír Čunát]

Hi,
I'm unsure about this, and a bit afraid not to over-engineer it.
Note: I have no non-negligible experience in other projects.

On 03/16/2015 12:43 AM, Austin Seipp wrote:
> And, as I'm sure most of you are aware, GitHub's notification system
> is not very lean. If you 'watch' a repository, you get spammed for
> every update to it!

I especially like the `participating` list, as it tends to be very 
small, so I can watch it often and react quickly.

Quite a nice github issue guide: https://guides.github.com/features/issues/

As for what issues/PRs to participate in, that's a little more 
complicated. I personally just read the title/subject of every issue/PR, 
and if I'm not interested, I can click on "mute thread" and never hear 
of it unless mentioned (some e-mail clients can also ignore/watch 
threads). This is because I can't imagine maintaining any kind of 
automatic filter that would well approximate my interests. A 
well-written title is a really powerful tool, and there aren't so many 
issues/PRs created yet, IMHO. (Count for new ones during the last month: 
131, i.e. 4-5/day, giving me estimate of 1-2 minutes/day to read the 
titles.)

Certainly, some specific tags are useful simple filters (e.g. security, 
darwin), and it seems that longer-running issues (>week) are more 
important to be triaged carefully. Those lasting for over a month are 
often quite difficult to close...


>   1) It would also be nice to adopt an official policy of maintainers
> for the source tree; e.g. who is responsible for certain NixOS or
> Nixpkgs subsystems, or Darwin/FreeBSD support, etc. This makes it
> easier to track down the right person, IMO.

For particular packages we have this. "Subsystem" responsibility might 
seem a little big commitment, and I'm especially unsure about contacting 
particular people *directly*. Most use cases should IMHO be covered by 
what we have already: an issue/PR label for each important subsystem, so 
people interested in it can easily watch it and react.

2) Triaging shifts: I can't well imagine such schemes for nixpkgs ATM. 
Well-named critical issues/PRs are IMHO very unlikely to go unnoticed 
for >24h, and for other I would mainly repeat what I wrote above.


And certainly +1 for having a short CONTRIBUTING.md, mainly consisting 
of links to information elsewhere, so things don't go duplicated much. 
For example, we have http://nixos.org/nixos/community.html


Vladimir


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3251 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20150316/86ba2ed0/attachment.bin