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