Hi Joel. Thanks for your input!
I understand that I put a lot into my proposal, but it's hard to estimate
timeline exactly. Thus, I suggest thinking about it as being ordered by
priority: most important things go first, and least important (like kernel
ITML) may be abandoned in favor of documentation / testing / etc if I run
out of the timeline.
The point about self-contained PRs is valid, I agree with you. Though, I'd
like to write a tutorial once the base is established (like, there're at
least 2 working algorithms). I'll think if I can reschedule my timeline
appropriately.
I understand that it takes some time to receive feedback for PRs. I think,
my current timeline works pretty good in that sense: after each 2 weeks
"iteration" (Preferably even earlier) I should have something for review.
Then I'll be working on a next piece of the project, while waiting for a
review feedback.
I'll elaborate my proposal later today.
On Tue, Mar 24, 2015 at 2:34 PM, Joel Nothman <joel.noth...@gmail.com>
wrote:
> Hi Artem, I've taken a look at your proposal. I think this is an
> interesting contribution, but I suspect your proposal is far too ambitious:
>
> - The proposal doesn't well account for the need to receive reviews
> and alter the PR in accordance. This is especially so because you are
> developing a new variant of the API which means that even if the algorithm
> works perfectly you won't get a free green light.
> - With an implementation of one or two algorithms two algorithms, it
> would be much better to add good examples of their utility and their
> features to the example gallery than to implement more algorithms.
> Developing good examples takes time too (and the reviewers are just as
> picky).
> - You will need to package your contributions into manageable PRs, and
> ideally after each is merged, the overall project should still be usable
> (well-tested, documented, etc.). So the documentation will, at least in
> some measure need to be integrated.
> - As Gaël suggested, there's some cause for concern in that it
> requires developing a new variant of the general API. This means everything
> is slower, including more need for sanity and integration testing than
> other projects may entail.
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Scikit-learn-general mailing list
> Scikit-learn-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scikit-learn-general
>
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Scikit-learn-general mailing list
Scikit-learn-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scikit-learn-general
