Hi Jaret.
Please stay on the mailing list so that everybody can answer.
For 5091, as I said, best discuss it there, and if you have a question,
just post it there. People that follow github will see it.
For finding bugs: If you see an issue and it looks fixed, definitely ask
"is this fixed in #XXXX. If not what remains to be done".
Often we overlook closing issues, and even if items remain open, it is
good to clarify what needs to be done so that people
can pick up the work.
You should definitely ask as many questions as you feel necessary.
Issue-related things best on github, general questions on the mailing list.
Cheers,
Andy
On 08/06/2015 12:10 PM, Jaret Flores wrote:
Andreas,
I just realized that you are amueller from github (looks like you've
gained or lost a beard). I hope you don't mind my emailing you
directly. My *simple* bug fix is #5091 and it is failing because
there was an "Error starting AppVeyor build".
One more question I have pertains to finding bugs to work on. As I
browse through the open issues, I find a bug and then follow
referencing issues. It is not uncommon that the chain of issues ends
up on a pull request that looks to solve the original bug. Even if
that pull request has already been merged, the original (bug) issue is
not closed and it's not clear to me if there is still more work to
do. Or perhaps the (original bug) issue has just been overlooked and
not yet closed. Is there a protocol to this? I don't want to annoy
others by double-checking "does #XXXX completely fix #YYYY, and if so,
should this ticket be closed...".
I'll try not to ask you too many questions, but I am a little new to
contributing to a large (for me) open source project and would like to
make sure I get off on the right foot. Thanks so much for your help
and responses.
-Jaret
On Thu, Aug 6, 2015 at 9:49 AM, Andreas Mueller <t3k...@gmail.com
<mailto:t3k...@gmail.com>> wrote:
Hey Jaret.
It is usually easier to discuss these things on the github issue
tracker.
Which is your pull request? Just ask there.
For the doctests you can do "make test-doc" that will run
nosetests with the appropriate options.
For the whitespace, there is an option to ignore whitespace
changes. grep NORMALIZE_WHITESPACE in the code to see an example.
The integration tests do the same as "make test" (basically). They
check multiple versions of numpy, scipy and python, though, which
is not entirely trivial to reproduce (you can create some
virtualenvs if you like).
The "expected" is just the string that is actually written in the
doctest. You need to fix that manually if the output changed.
Hth,
Andy
On 08/05/2015 04:28 PM, Jaret Flores wrote:
After working with the code a little, I have some follow up
questions. Please feel free to point me to other references.
1) Is there a way to run doctest tests for a specific package
similar to `nosetests`? Also, doctest tests seem to be sensitive
to formatting (spacing) and required a couple trials to get it
correct. Are there rules for this?
2) After submitting the pull request, there are continuous
integration tests. Is there anyway to run these tests prior to
submitting the pull request? Also, it seems my request has
failed due to a failing doctest test which passes on my own
machine. When looking at the travis-ci build output, it looks
like the code has been updated (the `Got` is current as per my
pull request) but the comment was not (the `Expected` was not
current). I am not sure how to proceed from here.
Thanks again
On Tue, Aug 4, 2015 at 10:08 PM, Andy <t3k...@gmail.com
<mailto:t3k...@gmail.com>> wrote:
Hi Jaret.
It totally depends on your what your interested in and
familiar with.
The issue tracker has lots of issues to fix, look at the
"easy" issues, the "need contributor" ones or the "bug" ones.
And definitely look at the contributing section:
http://scikit-learn.org/dev/developers/contributing.html#contributing-code
Code reviews of existing pull requests are also always
welcome of course.
After doing some "easy" fixes I can point you to more
challenging ones.
Cheers,
Andy
On 08/04/2015 10:18 PM, Jaret Flores wrote:
Since I've come into a good amount of free time lately, I
wanted to find a way to contribute. As it says in the
documentation, I wanted to check here to see what would be a
good use of my time. If anyone has suggestions as to where
I should devote some time, please let me know. Thanks.
-Jaret
------------------------------------------------------------------------------
_______________________________________________
Scikit-learn-general mailing list
Scikit-learn-general@lists.sourceforge.net
<mailto:Scikit-learn-general@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/scikit-learn-general
------------------------------------------------------------------------------
_______________________________________________
Scikit-learn-general mailing list
Scikit-learn-general@lists.sourceforge.net
<mailto:Scikit-learn-general@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/scikit-learn-general
------------------------------------------------------------------------------
_______________________________________________
Scikit-learn-general mailing list
Scikit-learn-general@lists.sourceforge.net
<mailto:Scikit-learn-general@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/scikit-learn-general
------------------------------------------------------------------------------
_______________________________________________
Scikit-learn-general mailing list
Scikit-learn-general@lists.sourceforge.net
<mailto:Scikit-learn-general@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/scikit-learn-general
------------------------------------------------------------------------------
_______________________________________________
Scikit-learn-general mailing list
Scikit-learn-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scikit-learn-general
