More examples - and validated examples - would be excellent!
I'll take the opposite position for purposes of debate on PEP8 in Travis.
I'm reluctant to include this for a few reasons that really boil down to
"the standard itself says to ignore the standard if it's more readable to
ignore the standard." All of the checkers are relatively stupid, so no
reasonable/readable exceptions will pass. Also, when the rubber meets the
road the purpose of Travis is to tell us *if it works or if something broke*,
not piddle around with style. I want to know if it works, not dig around in
a multi-thousand-line Travis log to determine if style was off or - maybe -
I have a real problem. Lastly, there are a significant amount of PEP8
exceptions in the repo right now, so getting this working even at baseline
would involve significant (IMO, not very productive) effort.
With practice and a decent editor it's fairly easy to write PEP8 compliant
code from the start. For new submitters this can seem a bit pedantic, but
treat it more of a learning experience rather than criticism.
I very rarely use IRC. Even if we had a channel, I'd be infinitely more
responsive via email / GitHub discussions.
Josh
On Thursday, May 16, 2013 10:22:54 AM UTC-5, Stefan van der Walt wrote:
>
> Hi Ankit
>
> On Mon, May 13, 2013 at 10:39 PM, Ankit Agrawal <aaaag...(a)gmail.com<javascript:>>
> wrote:
> > 1] Examples in docstring for every api function : Sympy's documentation
> > seems very comprehensive as all the api-functions have atleast one
> example
> > in the doc. By examples in skimage, I mean the commands operated on
> standard
> > images(lena, camera or a particular ndarray that can explain the
> > functionality better) which a user can try out himself in his own shell.
>
> We'd love to have more examples, but we should first update our test
> machinery (specifically .travis.yml, make test) to run those as well.
>
> > 2] Code quality/PEP8 checks in Travis tests : This could reduce the
> energy
> > spent on discussing code quality errors while reviewing pull requests
> made
> > by new contributors and concentrate more on other aspects of the code.
>
> +1!
>
> > 3] IRC channel #skimage : For some kind of queries/discussions, IRC
> channel
> > proves more useful and provides a fluid connectivity between the
> community
> > members. All the conversations can be logged so that they can be
> referenced
> > in the mailing list or github if needed.
>
> I don't mind an IRC channel, but I don't really use that mode of
> communication often. How about the others?
>
> Stéfan
>