Task board

Stefan van der Walt stefanv at berkeley.edu
Fri Sep 2 19:59:03 EDT 2016


Hi Egor

On Fri, Sep 2, 2016, at 01:54, Egor Panfilov wrote:
> 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 still don't see any explanation of what the term 'l2hys' means!

>  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

This is true, unfortunately.  How do we increase the number of hours
available?  I can see two ways: grow the contributor community (in such
a way that contributors know to review as well) or hire someone to work
on the project full time.  I'd be interested in exploring the latter
avenue.  We can also reach out to employers of existing contributors and
try and negotiated dedicated working time on the project.

> 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 issue I wanted to address was getting a good "bird's eye view" on
issues.  I don't think tags are that useful in that regard.

> From the pricing perspective, Zube is not the best choice as it offers
> Free plans for teams up to 4 people. I think

No, Zube is free for open source, for unlimited users.

> (I'd __love__ to have RFCs, not just random discussions in
> issues/mailing list), Trello (trello.com) could be also a nice choice.

You mean RFCs like PEPs?

> 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.

I'd be fine with that.

> outines 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.

We do evaluate these things from time to time.  When GPUs came into
fashion, we looked at those, at a recent conference I spoke to folks
about using DSLs like Halide for speed optimization, and with our GSoC
student Daniil we've spoken a lot about integrating neural nets.
Adopting theano may be quite tricky, so perhaps a proof of concept (or
an RFC ;) would be the easiest way to kick off that conversation.

> 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.

Can you explain what you mean?

Thanks for all your comments,
Stéfan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20160902/50f19488/attachment.html>


More information about the scikit-image mailing list