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+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/CAP0v5tm5C4%3Df9c9u1juf37yYpXipkZU%3Ds1zwVO5GMikqnB2KVQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to