Thank you all for responding. I general, I agree that the "easy ND contributions" should be addressed ASAP. That said, it seems that there there is consensus that the ND conversation can be moved later in the PR cycle when most of the other issues have been address, docstrings, testing for the 2D case, API choices, "fit", examples, gallery. I think many of you rightfully pointed out that good code is often generalizable to ND quite readily. My hope is that by delaying the ND conversion, the PR will be in a really good state, that it will be an "easy fix". Lars, I will have to have a detailed look at your PR. On Wed, Aug 7, 2019 at 9:48 AM Alexandre de Siqueira < alex.desiqueira@igdore.org> wrote:
Hey everyone,
Alexandre, something that I want to emphasise right now is that I
would like to consider the next ~12-24 months a sprint to 1.0.
Therefore, I want to avoid as much as possible taking on new
technical debt and focus on fixing/cleaning everything we have so far, according to our (as yet not ratified) values. [1]
We're in the same page, Juan :) Thinking on that, it would be interesting to have something on our model close to Debian Linux's release cycle. We'd work on and receive major contributions up to a certain point (let's say, the next 6-12 months). Then, we clean and debug everything we can, not accepting new major code for that release; it'll be something like Debian's frozen cycle. But I'm digressing.
Kind regards,
Alex
On Wed, 2019-08-07 at 00:24 -0500, Juan Nunez-Iglesias wrote:
Thanks Mark for raising this and Lars and Alex for weighing in.
On Mon, 5 Aug 2019, at 5:40 AM, Alexandre de Siqueira wrote:
I think what is important is to keep the API forward looking for ND. We can do things like accept tuples for parameters, instead of "x_center", "y_center", or "r_center", "c_center". We can also just throw errors when people pass in higher dimensions images saying that it isn't implemented and contributions are welcome.
I think this is critical and really like this compromise. Don't do more work than is actually needed while not making future work harder. Equally critical to me is that whether a function supports ND or only 2D is clearly documented. Maybe after a parameter's type declaration in the docstring?
I guess these are all good solutions for us right now. I'm sure that we'll break, fix and clean lots of stuff/code/API until we reach 1.0 (and that is okay™). This problems will be tackled naturally on the way.
I agree with Lars, keeping the *API* nD-compatible is already a very good step towards keeping the Guardian of the Dimensions happy. =P Great suggestion, Mark!
Alexandre, something that I want to emphasise right now is that I would like to consider the next ~12-24 months a sprint to 1.0. Therefore, I want to avoid as much as possible taking on new technical debt and focus on fixing/cleaning everything we have so far, according to our (as yet not ratified) values. [1]
Optimizing for the different use cases is just tricky, and won't be done correctly if contributors are asked to include something they have no immediate need for.
We can help in some of these cases. If we (core group) can't, we can: 1. discuss if the algorithm is ready as-is to be included and upgraded from there; 2. ask for external community help.
My main idea is that I am happy to jump in and make things nD at the PR stage. However, I don't have the bandwidth to do this for *all* contributions and help is always appreciated. This is why it's important to be on the same page.
Additionally, as I raised in the SEEDS PR [2], a contribution might be worthwhile in nD but not worthwhile in 2D, because 2D implementations in Python already exist. (And in this case they have a good chance of being faster than ours!) We are having enough trouble keeping up with the maintenance burden as it is, so the value of new contributions to the community should be weighed against the maintenance burden.
It might be time to revisit the idea of skimage-contrib, a repo in which functions that don't quite meet this benchmark can live, until they are ready to graduate.
In that vein, wasn't there a discussion about writing a guide on ND-algorithms (e.g. the raveled approach used in watershed, local_maxima, flood_fill)? Was there any progress on this? I think this could be really useful to the community and a good resource for new contributors regardless of how skimage's policy on this turns out.
+1. Or even, contributors aiming to enhance our 3D/nD possibilities, only :)
Yes, I mentioned that I should write a guide and here we are, no further along. Apologies for that. I'll prioritise this work for the summer/fall. If we have an easy guide, including pointing to PRs or commits that convert code to nD, that will make things a lot easier.
Juan.
.. [1] https://github.com/scikit-image/scikit-image/pull/3585 .. [2] https://github.com/scikit-image/scikit-image/pull/1557 _______________________________________________ scikit-image mailing list -- scikit-image@python.org To unsubscribe send an email to scikit-image-leave@python.org
-- -------------------------------------------------- Dr. Alexandre de Siqueira Berkeley Institute for Data Science - BIDS 190 Doe Library University of California, Berkeley Berkeley, CA 94720 United States
Lattes CV: 3936721630855880 ORCID: 0000-0003-1320-4347 Github: alexdesiqueira -------------------------------------------------- _______________________________________________ scikit-image mailing list -- scikit-image@python.org To unsubscribe send an email to scikit-image-leave@python.org