[zeromq-dev] dealing with stale github issues

Luca Boccassi luca.boccassi at gmail.com
Sun Sep 30 12:05:00 CEST 2018

On Sat, 2018-09-29 at 08:04 -0400, Wes Young wrote:
> hi,
> as i’m catching up on my somewhat stale czmq/zyre/tls/gossip/tls
> forks, i’m weeding through the issues on czmq and zyre and thinking
> “2016? is this still an issue?” for a number of my own github
> projects i’ve started enabling the stale app on github to just remove
> things that either aren’t problems or aren’t problems worth solving.
> https://github.com/apps/stale
> has anyone brought this up for some of the zeromq repo’s (i may even
> have, i forget)? i’m a little more aggressive with my own repo’s
> (assuming people log issues and don’t submit a PR to fix the problem,
> after 21-45 days they get closed). having spent the last few years
> digging through the guts of ZAP, TLS, Zyre, GOSSIP, etc.. 21 days may
> be a bit harsh… maybe something simple like 12mo for some repo’s and
> see how it plays out?
> the biggest concern i have is [for myself] figuring out what and
> where i can dive into stuff when i have a spare cycle here and there-
> i can only imagine some new users might feel the same overwhelming
> “where do i start?” when looking at obviously stale issues that go
> back to 2016, 2015.. or worse- “this project has too many bugs! and
> clearly no one is paying attn”.
> even if you wanted to fix some of them, you’d have to start over
> again (find the original complainer, get data, etc) anyway. i’ve
> tried that a few times, things just go stale, people get busy and it
> doesn’t help that these projects sometimes move really fast, leaving
> some of these issues irrelevant anyway.
> if i owned the world, it feels like 6-9mo is a good number, 12mo is
> probably a good start though for projects like this imo. it’s not
> like you can’t find these later if they re-surface (and re-open), but
> it’s a lot of noise imo. i’m thinking Zyre (and maybe czmq?) might be
> a good place to test this? thoughts? has this been brought up before
> (and squashed)?
> this community has done a great job at keeping the PR queue clean,
> something that’s brainwashed me into HATING ANY PROJECT that doesn’t
> do that. i think the issues queue is the next step in that evolution.
> happy to take critisism's, just trying to make it easier to get
> involved w/o having all the legacy baggage. ymmv.
> thanks for all that everyone here does!
> --
> wes
> github.com/wesyoung
> csirtgadgets.com

I think it would be a good idea, 12mo should be fine for czmq/zyre.

For libzmq every now and then we do a manual pass and try to close old
issues that we know have been solved - I've done this last year, Simon
did it more recently, but yes old issues rot. For libzmq perhaps
something like 2 years would be more appropriate.

Kind regards,
Luca Boccassi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20180930/d2085648/attachment.sig>

More information about the zeromq-dev mailing list