Hi, everyone As Juan mentioned recently, it's becoming harder to keep track of the motion of the project as a whole. Sometimes, tickets lounge unattended for an unacceptable long time. I can think of two main routes for improving the situation: 1) Improve our team structure, so that individuals take responsibility for moving certain aspects of the project forward. 2) Processes / systems to help us get a grasp on the current state of things I have some ideas around (1) that need fleshing out, but in the mean time I was looking at http://zube.io to address part of (2). Do you have any experience with this system? Zube can be compared against HuBoard, gh-board, and ZenHub. A test scikit-image board is here: https://zube.io/projects/4670/kanban (it's vanilla, I haven't done anything with it yet) Let me hear your thoughts. Stéfan
Hi Stéfan, thanks for continuing the discussion on this important subject. I would reformulate your two points as 1) social aspects/community management and 2) technical tools and processes. 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. I don't have much to say about the 2nd point since I don't know the tool. For the 1st point, here are some ideas and suggestions from the top of my head - assigning / self-assigning PRs might be a good idea, as Juan suggested - when a PR is stalling and the contributor is not responding, we should either take over if possible, or close it after some warnings. - keeping a good balance between the number of active contributors and active reviewers is hard. Recently several people have contributed several PRs, demonstrating an expertise in some domain of image processing. Maybe we should ask them whether they would be willing to review PRs and be more active in including these persons. - 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 know that there are periods of time where I can't spend any time on scikit-image, it can be weeks or even months. If the rest of the team had such information for every core member, it would save time because someone else could try to take over. We could also have pairs of people with similar expertise (segmentation, computer vision, architecture, etc.), who could work in pairs and replace the other person when one is not available. - 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. 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. Cheers, Emma On Mon, Aug 29, 2016 at 01:17:48PM -0700, Stefan van der Walt wrote:
Hi, everyone
As Juan mentioned recently, it's becoming harder to keep track of the motion of the project as a whole. Sometimes, tickets lounge unattended for an unacceptable long time.
I can think of two main routes for improving the situation:
1) Improve our team structure, so that individuals take responsibility for moving certain aspects of the project forward. 2) Processes / systems to help us get a grasp on the current state of things
I have some ideas around (1) that need fleshing out, but in the mean time I was looking at http://zube.io to address part of (2).
Do you have any experience with this system? Zube can be compared against HuBoard, gh-board, and ZenHub. A test scikit-image board is here: https://zube.io/projects/4670/kanban (it's vanilla, I haven't done anything with it yet)
Let me hear your thoughts.
Stéfan
Hi Emmanuelle On Mon, Aug 29, 2016, at 14:38, Emmanuelle Gouillart wrote:
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.
- 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.
- 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? Stéfan
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
Hi Johannes On Tue, Aug 30, 2016, at 12:58, Johannes Schönberger wrote:
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...
Did you look at the proposed Zube (or the alternatives)? I'd be curious to hear what you think.
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?
We can extend our release script to pull that information from GitHub. Would it be helpful to credit with new releases, or should this come as more continuous feedback, e.g. a weekly mail to the list with statistics? Stéfan
On Mon, Aug 29, 2016, at 13:17, Stefan van der Walt wrote:
I have some ideas around (1) that need fleshing out, but in the mean time I was looking at http://zube.io to address part of (2).
Take a look at this! https://github.com/blog/2256-a-whole-new-github-universe-announcing-new-tool... E.g., here's an empty project to play around with: https://github.com/scikit-image/scikit-image/projects/1 Stéfan
participants (3)
-
Emmanuelle Gouillart -
Johannes Schönberger -
Stefan van der Walt