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.
