Hey friends!

I just felt it was about time I'd explain how I typically use KNOWN_BUGS and
bug reports without activity for a long time. If you think we should do it
differently, then please tell me and suggest a different approach!

  The issue tracker (on github) works great to keep track of current bugs and
it makes sure we don't accidentally forget or ignore bugs people have
experienced. I actaully these days prefer to have bugs reported there instead
of or in addition to the mailing list.

  Bug reports that linger in the bug tracker for a long time (like months) that
aren't getting traction from anyone on the team and not from any bug
reporter(s) tend to just "get in the way" of the bugs we consider important
and interesting and are working on actively. Obviously those bugs are too
hard, too cryptic, too rare, too uninteresting or something else like that.
Ideally of course, no truly important bug (whatever metric we can have for
that) should ever go stale. If they still legitmately point out a problem, I
go through the issues every once in a while, add then to KNOWN_BUGS (with a
link to the issue tracker) and close them on github. I usually label them
"KNOWN_BUGS material" a few weeks before I actually move them over.

Bugs that we can't reproduce or don't understand that aren't getting enough
attention from the reporter get closed instead of moved.

This makes the issue tracker only hold somewhat "active" bugs. Older ones are
in KNOWN_BUGS.

All members of the "curl team" on github have permission to close or re-open
issues.

Everyone is free and encouraged to help out to fix bugs or to comment on
existing bug entries. Fixing bugs is very time consuming work.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html