Hi Eric,
Yes, this became evident right away after the transition; in addition,
there was a coordination glitch such that quite a few bugs that I had
closed on SF, trying to clear out some junk before the transition, ended
up getting resurrected on github, complete with dead links.
Got it, I missed that previous discussion.
This is a triage situation; we have to consider the cost/benefit
tradeoff of various ways of dealing with the mess, and with the glut of
bug and other reports. The fact is that we were way behind in dealing
with the SF bugs, and we are falling behind in dealing with github bugs.
I think the best approach is to be fairly brutal in closing bug reports.
We don't have the developer time to deal with very many. Those that
accumulate faster than we can deal with them merely cost us time
whenever one of us scans the set of reports in an attempt to get the
list under control by finding ways to close a few.
It's unfortunate that github doesn't offer a 'priority' field so that
one can threshold on it. We use 'prio-X' labels with X in {low,
medium, high, blocker} as a substitute, but there's no way to see 'all
with prioirty >= high', for example.
But we've been trying to aggressively label everything with a
priority, and in practice only high/blocker ones really get worked on,
unless someone external shows up with a pull request for anything
below that.
My take right now is that even bugs are almost all lower priority than
pull requests: if someone took the time to actually contribute code, I
think it's critically important to get back to them with feedback.
Not having a timely review and response to a PR is the best way to
discourage potential new contributors. My hope is that by being
pretty aggressive on that, we'll grow our developer pool enough to be
able to make some headway into the bug backlog. One can dream... 
So, the dead SF links are the least of our problems; not that big a
deal. We would lose little by simply closing all of the transfered
reports; or at least closing all of those older than some threshold.
You're probably right, though I sort of prefer to keep an open bug if
the problem really isn't resolved. But marking all SF bugs with
priority low (if you decide to create a similar set of priority
labels) would at least indicate this intent, and let you focus only on
the real problems more easily. Because actually closing them raises
the risk that they will get re-reported, and then it's even more work
to start linking bugs or closing dupes.
Ultimately though, we're all (mpl, ipython, scipy, etc) suffering from
the same problem: despite the enormous growth in the user base of the
scientific python tools in the last few years, the developer pool has
not really grown at the same rate. Our projects are have dangerously
small core teams. I wish I knew how to change this...
Cheers,
f
···
On Sun, Jan 29, 2012 at 1:35 PM, Eric Firing <efiring@...229...> wrote: