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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev
