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 -- You received this message because you are subscribed to the Google Groups "scikit-image" group. To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscr...@googlegroups.com. To post to this group, send an email to scikit-image@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/scikit-image/F7732EB1-2CFF-4ABE-A3DD-E4444E4AF621%40demuc.de. For more options, visit https://groups.google.com/d/optout.