Task board

[Johannes Schönberger]

To better keep track of PR/issues, I suggest core developers assign themselves to some of the issues in their field of expertise. There are so many PRs that are >90% finished but it seems we forgot to continue reviewing them.

> On Sep 4, 2016, at 10:32 AM, Egor Panfilov <multicolor.mood at gmail.com> wrote:
> 
> Hi Stefan!
> 
>> 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.
> 
> Yes, I see. I think, this could be helpful for project owners to make strategic decisions. On the other hand, I personally don't find a great benefit of using these tools for triaging, cross-linking issues/PRs and other cases I care about. Maybe we should just give it a try.
>> 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.
> 
> Indeed, sorry, I see this now.
>> (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?
> 
> Exactly. I think, this format would help to accumulate our opinions on different matters (e.g. how to we treat and depend on `matplotlib`), for which website (deeply buried pages of it) is not the best place. At the moment, discussions on many sensitive topics appear again and again in the different PRs, making them hard to align and to be referenced.
> As for technical side of this, we probably could reuse GitHub issues (by creating exclusive tag "SkimageEP" or something similar). `matplotlib` people, as far as I know, use GitHub Wiki to post "xEP"s, but I'm not sure where do they held the discusssions. GitHub does also support protecting different pages from modifcation, that could also be useful.
>> 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?
> 
> Well, I'm just saying that we as a core team should drive the evolution of backend and make life easier for contributors and users. Like, try to imagine some new contributor making a PR introducing Sphinx Gallery. Can't see this happenning. Of course, all of us are working on this kind of features already, I just want to highlight this (maybe trivial) point.
> As a "practical guide", perhaps we should dedicate more time to the _complex_ issues/requests/PRs we have.
> 
> 
> Thanks for all your comments on Theano/GPU/whatever part (/cc Emmanuelle, Johannes), they're very informative and insightful. I'd prefer to raise this discussion again (as I have more food to bring to the table) or maybe just collect your opinions in one place when (and if) we decipe on SkimageEPs.
> 
> Regards,
> Egor
> 
> -- 
> 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+unsubscribe at googlegroups.com.
> To post to this group, send email to scikit-image at googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/scikit-image/CAP0v5tm5C4%3Df9c9u1juf37yYpXipkZU%3Ds1zwVO5GMikqnB2KVQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.