Hello everyone! Here are some of mine reflections on the topic:
Regarding the points raised by Stefan, I think that the main issue we have is a lack of resources and reviews (just a casual bump of https://github.com/scikit-image/scikit-image/pull/2040 here ;) ). I understand that everyone in the core team has a lot of matters to deal with outside the project, but the activity from our (maintainers) side is far less compared to the activity of the contributors. In my opinion, people tend to quit contributing and even stop using OSS if they don't have enough treatment. Of course, many of the PRs we currently have are quite poor in terms of quiality and/or abandoned (we have to be more aggressive managing them), but those which are pretty good, maybe not perfect, totally deserve to get much more attention (e.g. https://github.com/scikit-image/scikit-image/pull/1957, https://github.com/scikit-image/scikit-image/pull/1570, etc). I'd prefer to have slow (pure Python) implementations of established image processing algorithms and make more people involved in the project rather then asking them to write an extremely fast and ideal code and losing them in process. So, pt.1 - "we should do more and grow the active community". As for issues/PRs management system, I think that GitHub tags pretty much do the deal. We've recently added "status: xxx" tags to facilitate tracking of active/abandoned/WIP/review+1 issues/PRs. The only _extra_ feature I'd personally prefer to have is issues/PRs aging, so to easily observe which of them haven't gotten any activity recently. If the management system offers this kind of functionality, I'd be glad to give a shot testing it, otherwise I'm neutral about this. >From the pricing perspective, Zube is not the best choice as it offers Free plans for teams up to 4 people. I think that https://waffle.io/ could be a better alternative. Here you can see a preview https://waffle.io/scikit-image/scikit-image . From my knowledge, Waffle is one of the first services of this kind, so should be well-designed from the UI perspective. If we'd like not just to manage open GitHub issues/PRs, but have a more structured backlog for our discussions and RFCs (I'd __love__ to have RFCs, not just random discussions in issues/mailing list), Trello (trello.com) could be also a nice choice. It has awesome GitHub integration and many more features. Although, I'm not sure that devs would like to get acquainted with this heavy system just for a single project management. Pt.2 - "issues/PRs management tool for stronger management, not just for its own sake". P.S. I like the practice of `scikit-learn` guys to rename PRs as "[MRG] some awesome contribution" -> [MRG + 1] some awesome contribution". Pretty simple and cheap solution to track LGTM :+1: entities. One more point (yet it is better to start a discussion in a RFC :) ) I'd like to bring to the discussion. I remember a short discussion with Stefan, that there was a decision upon that `skimage` is a community driven-project. I understand, that it is probably mostly used for educational purposes, but we shouldn't as a project fall behind the progress in Image Processing and Computer Vision. I see that many modern Deep Learning frameworks start to implement their own image processing routines just to have a common ground for their functionality. I believe we could still catch the train. So, I propose to consider moving `skimage` infrastructure onto `theano`. That is a hell lot of work, of course, but I'm asking just for a discussion yet. >From this section, actually, one more pragmatic topic arises. Even if we keep image processing part up to the community, I think that we have to put more our (core team) efforts on the backend part of the project (not just testing and documentation part, but also e.g. make easier function chaining - https://github.com/scikit-image/scikit-image/issues/1529). I'd not expect from anyone outside the core team to have enough knowledge, experience and confidence to implement this and some other features. I.e. I believe that we have to make some necessary contributions to stay competitive. +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. I fully agree with you, Johannes, but have not a single idea on how to implement this. Well, we still can set up a GitHub bot (sorry, I'm being unreasonably hyped by this tech these days) and track who participated in the review process for each PR, but I'm definitely not sure how fair it could be (what if I just comment something like "LOL" in 1e6 lines of code PR and got credited for that) and what kind of appreciation one might expect (like, "this person has reviewed a lot"). Ofc, we can track who put "LGTM" or "+1" on the PR page, but this isn't a fair solution either. We are already publishing "list of fame" with every new release, and an organization badge in GitHub account is self-speaking. I guess that's the most safe option we could have at the moment. Sorry for the long read. :) Have a nice we. Regards, Egor Panfilov 2016-08-31 2:54 GMT+03:00 Stefan van der Walt <[email protected]>: > 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 > > -- > 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 [email protected]. > To post to this group, send an email to [email protected]. > To view this discussion on the web, visit https://groups.google.com/d/ > msgid/scikit-image/1472601249.1617176.710940585.4C1ED035% > 40webmail.messagingengine.com. > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To post to this group, send an email to [email protected]. To view this discussion on the web, visit https://groups.google.com/d/msgid/scikit-image/CAP0v5tn%3Dcus%3DEKKdS_cBOU%3Dusy0sDzpvSEuAOVJJwWWiKV6nXA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
