Hi, Please, find my comments inline.
In my opinion, we need a little bit of both. Dashboards can be useful if they save time and provide meaningful information that would be painful to retrieve otherwise. One should nevertheless be wary of too many metrics and quantitative indices (a problem that cripples the creativity of scientific research!): it is sometimes very tempting to merge two small PRs instead of spending time on a single difficult one.
What I liked about Zube is that it has the potential to give you a good "bird's eye view" of PRs. We could probably achieve the same using (tags + some script), or (tags + gh-board). But it's good to know what's being worked on, what's on the back-burner, etc. in one glance. I don't care too much about metrics and burndown charts etc., which I think are less applicable to a community driven project.
I agree that Github does not provide a good overview of active/passive issues. I am overwhelmed by the amount of issues and, usually, after a week of scikit-image "abstinence" :-), I have to start from scratch to find the relevant issues. Tags don't really help me in this regard either...
- when a PR is stalling and the contributor is not responding, we should either take over if possible, or close it after some warnings.
We should feel confident to triage more aggressively. Open tickets that hang around also sap resources, in making it harder to find the right things to work on when you only have a little bit of time.
+1, there should be a cleanup of old issues that are stale for months if not years.
- in the core team, maybe we should say more explicitely when we are or are not available (announce it somewhere? have a google calendar?).
I think this ties in with your next point. It's hard to track calendars; perhaps more practical is to track commitment? There is already a (dangerous) notion of "first person to comment essentially owns the review for the PR", but we should make it more explicit: both so that folks don't feel afraid to review PRs ("oh no, I'm becoming responsible for this thing!") and so that there is someone actively watching over its progress. That way, we can also easily find PRs that have no "owners".
- we could take turns to be in charge of checking the global advance of PRs. It's a pain of a job, but if it's one week every two months it's not so bad.
I like this idea; I've been wondering how we could move "ownership" of the project around to create better focus and more autonomy, and this may be a good, gentle start to that.
I'd be curious how others felt about this idea?
Here are my 2 cents. I think it's a question of focussing our resources better, and maybe empowering new people, because I'm not sure we can spend much more time on the reviewing process.
Growing the core team is crucial. Our user base is growing nicely, but that is not helpful unless we convert a certain percentage of those users to contributors. And it should be clear to contributors that reviewing is a priority and a good way to become involved (everyone wants to code, though :).
We have a document (http://scikit-image.org/docs/stable/contribute.html) that invites users to contribute, but we can simplify those instructions for newcomers, and also add a "Please help us review some code" button on the front page?
+1, In my opinion, reviewing is almost more important than writing the code. With the current system, Github only "rewards" people who contribute code and, I think, this is part of the problem. With every commit, people get credit in the form of # commits or # lines of code and Github shows the stats nicely in the profile or the project graphs. Maybe there is a way to create an equivalent for the reviewing process, e.g., # comments and # merged PRs. What do people think about this idea? Best, Johannes