GSoC 2013

[Aaron Meurer]

So Google has announced Google Summer of Code 2013. Here's the
timeline: http://www.google-melange.com/gsoc/events/google/gsoc2012.
We need to have our org application and ideas page ready by March 9,
which is sooner than it sounds.

The ideas page is at
https://github.com/sympy/sympy/wiki/GSoC-2013-Ideas, the org
application is at
https://github.com/sympy/sympy/wiki/GSoC-2013-Organization-Application,
and the student application template is at
https://github.com/sympy/sympy/wiki/GSoC-2013-Application-Template.
So far, they are just copies of last year's stuff. So we need to go
through the ideas page and remove any ideas that are no longer
relevant, and also add some new ones. If someone wants to attempt an
organizational cleanup of the page as well, that would be great too.
We also need to go through the organization application and student
template and update stuff. We won't know the actual questions until
February 27 when the application period starts, but in the past they
have been almost exactly the same. Any help here is greatly
appreciated.

Now, to the main issue. Who is willing to mentor this year? If you
are willing, please add your name to the bottom of the ideas page.
It's OK if you are only able to mentor certain projects. Just note
that. Even if you are on the fence, add your name. The more potential
mentors we have, the better it looks to Google when they are reading
our application. When it comes down to it, you won't have to mentor
anybody unless you want to.

If you've participated as a student before, I encourage you to
consider mentoring. You may also apply as a student again if you
want.

To the people who helped review applications last year, are there any
changes you would like to see to the application template this year? I
know that there was a session at last year's mentor summit about this,
which Matthew, GIlbert, and Stefan attended. It would be great if you
guys could review the template with that session in mind.

To anyone who is interested in applying to Google Summer of Code as a
student, I recommend you read through
https://github.com/sympy/sympy/wiki/GSoC-2013-Application-Template.
Then, introduce yourself on this list (if you haven't already), and
get started on fulfilling your patch requirement. You should also
start discussing what idea(s) you are are interested in. We look
forward to meeting you.

Aaron Meurer

[Stefan Krastanov]

I have added myself to the "willing to mentor" paragraph. I the next
week I will try to help with the cleanup/update of the templates.

> --
> You received this message because you are subscribed to the Google Groups "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
> To post to this group, send email to sy...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sympy?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Aaron Meurer]

By the way, if you are planning on making significant changes to one
of the pages on the wiki, and you have push access to sympy, I should
note that you can clone the wiki repo with git (see
https://github.com/sympy/sympy/wiki/_access), edit the files locally,
and push them up. This is also a good idea if you suspect someone
else might be editing the wiki at the same time, because the web
interface doesn't do anything about merge conflicts, but with git, you
just get a regular git merge.

Aaron Meurer

[Aaron Meurer]

Another thing that would help is if you all could fire up your IRC
clients when you are at your computer and idle on #sympy. Quite a few
people come to that channel for information about GSoC, but often no
one is around to answer their questions.

Aaron Meurer

[Ondřej Čertík]

On Mon, Feb 11, 2013 at 3:02 PM, Aaron Meurer <asme...@gmail.com> wrote:
> So Google has announced Google Summer of Code 2013. Here's the
> timeline: http://www.google-melange.com/gsoc/events/google/gsoc2012.

I think the correct url is:

http://www.google-melange.com/gsoc/events/google/gsoc2013


Thanks Aaron for pushing it, I'll help with the application. I put
myself as a mentor too.

Ondrej

[Aaron Meurer]

Oops! Gotta be careful with that, because they didn't change the logo this year.

Aaron Meurer

[Aaron Meurer]

It also means that the dates I gave are wrong. The application
deadline is actually March 29 and the application period begins March
18. That gives us more time than I had originally thought, though we
should still get going on this now, especially with the ideas page,
because now that the program has been officially announced, students
are going to start coming to SymPy and looking at it.

Aaron Meurer

[Ondřej Čertík]

On Mon, Feb 11, 2013 at 8:40 PM, Aaron Meurer <asme...@gmail.com> wrote:
> It also means that the dates I gave are wrong. The application
> deadline is actually March 29 and the application period begins March
> 18. That gives us more time than I had originally thought, though we
> should still get going on this now, especially with the ideas page,
> because now that the program has been officially announced, students
> are going to start coming to SymPy and looking at it.

Yep. What ideas/projects do you think are high priority (or important) in sympy?
Or do you prefer to simply list all good ideas and simply let students choose?
I have a few ideas for projects, that I will propose in more detail/guidance,
and then we can have just random good ideas where the students can get inspired.

Ondrej

[Sergiu Ivanov]

Hello,

On Mon, Feb 11, 2013 at 04:02:23PM -0700, Aaron Meurer wrote:
>
> Now, to the main issue. Who is willing to mentor this year? If you
> are willing, please add your name to the bottom of the ideas page.
> It's OK if you are only able to mentor certain projects. Just note
> that. Even if you are on the fence, add your name. The more potential
> mentors we have, the better it looks to Google when they are reading
> our application. When it comes down to it, you won't have to mentor
> anybody unless you want to.

Unfortunately, I will most likely be very busy with other stuff this
spring and summer. However, I will readily devote my spare time to
helping people out. Do you suggest that I add myself to the mentors
list anyway?

Sergiu

[Aaron Meurer]

You can still help us review applications. I would not add your name
to the wiki unless you are actually willing to mentor, so that I can
see who exactly we have who can mentor people, but when the time comes
to review applications, let me know if you are interested in helping
out, and we can add you in.

Aaron Meurer

[Matthew Rocklin]

My notes from the mentor summit on the application are below.  If I get a chance I'll edit the template with these in mind.  I'm posting them here in case I forget. 

Application process

How should we improve our application process to attract good students, detect good students, and match good students to appropriate mentors?

We should ask indirect questions to query for curiosity and passion.

Negative examples:

Why do you want to work on SymPy?
Why do you like Math?
How long have you been programming?

Positive examples:

Copy the favorite snippet of SymPy code you’ve seen here and tell us why you like it.
What aspects of SymPy do you like the most?
What editor do you use and why?

Experience was that direct questions tend to have low information content (everyone says the same thing). Indirect questions will be ignored by the lazy but engage the engaged. You often want to test for curiosity and passion more than actual experience in the domain.

We should match mathematically strong students with strong programmer mentors and strong programmer students with strong mathematical mentors. We often do the opposite due to shared interests but this might result in ideal contributions

Aaron Meurer

[Aaron Meurer]

As always, I encourage students to apply for those projects that are
most interesting to them. If it's on the ideas page, then it means
that we want it implemented (modulo some cleaning up of the ideas page
as I mentioned earlier), so it's not like we won't accept them because
they are proposing to do something we don't want. If they want to
suggest an idea that's not on the ideas page, that's fine, and it
should be clear after discussing it with us whether we would accept
the idea or not.

With that being said, I consider these to be the highest priority
projects (in order, most important first):

- Completely move to the new assumptions system. This means we have a
good API for the new system, the old system is completely gone (and
the core is cleared of assumptions), the new assumptions have all the
power of the old ones (and ideally much more), and are well
documented, all the logical implication stuff is done correctly so
that they are fast, etc. This is unfortunately a hard project because
it requires a bit of knowledge of SymPy already. It also requires a
good knowledge of Python, including some of the more advanced language
features like context managers, and possibly metaclasses.

- Additions to the polys, especially involving algebraic
numbers/functions. I put this next because unlike the other items in
my list, this one requires a very high level of mathematics (probably
some graduate work in algebra), and therefore it will be a rare find
if a student comes forward who can do it. Our ability to do things
like implement the algebraic part of the Risch algorithm or improve
our simplification of algebraic expressions (basically, anything with
roots in it) depends on this.

- Refactor the polys for speed. In particular, we need to move to a
sparse representation, as the current dense representation is too slow
for polynomials of more than just a few variables. This project may
actually be a prerequisite for the previous one: if things are too
slow to do anything useful, it won't matter what algorithms we have
implemented. We won't even be able to effectively test them, much
less use them.

- Fast linear algebra. The idea here is to refactor the matrices to be
more like the polys, i.e., in a layered structure. At the bottom
there should be the ground types, which would be the same as the polys
ground types. This would let us have matrices over fast gmpy
rationals, or even matrices over rational functions, which
automatically reduce themselves to zero. This would also leave room
for abstraction against different internal representations, like
sparse or dense.

These are, in my opinion, the most important things to be done for the
core of SymPy. Others may disagree. But note that these ideas are
mainly targeted to maximize the speed/capabilities of all of SymPy.
If you are interested in the most important things for some particular
submodule, we could probably determine that as well. I don't know
about all the submodules. I could tell you pretty accurately what the
most important things to be done in the integration module are, for
example, but I have no

[Matthew Rocklin]

I think that we should highlight the "important projects" in the ideas page.  I also think that we should supply more concrete goals, perhaps in the form of a list of issues.  If I get time I'll try to think of a few for new assumptions.  In short I think that we need to manage these projects more explicitly.

If we give a more structured list of goals then the applications will have less information (they'll just copy-paste what we write) and we'll need some other mechanism to judge students.

[Matthew Rocklin]

I'm happy to serve as secondary mentor on any of {assumptions, matrices, stats, rewrite-rules}.  I don't think I'm sufficiently on top of things to be an effective mentor this year.  Let me know if you'd like me on the list.

[Aaron Meurer]

> Experience was that direct questions tend to have low information content (everyone says the same thing). Indirect questions will be ignored by the lazy but engage the engaged. You often want to test for curiosity and passion more than actual experience in the domain.

I like this idea. We already ask what environment students use.

But I think the main focus of the application is to see if students
are able understand their own project. We should ask questions that
attempt to make this clear.

My main question when I created this session idea was whether or not
we should abandon, or at least refactor, the timeline portion of the
application. On the one hand, it forces the student to think about
exactly what they are going to do. On the other hand, it is never
accurate (students always overestimate what they can complete in a
given amount of time), and yet students still try to stress over
making it accurate. What are your thoughts on this?

> We should match mathematically strong students with strong programmer mentors and strong programmer students with strong mathematical mentors. We often do the opposite due to shared interests but this might result in ideal contributions

I'm not sure about this. It sounds like a good idea, at least to
match a strong programmer with a weak one, because we want to watch
out for amateur mistakes, and give suggestions for things that the
student probably would never think of (e.g., a more elegant object
oriented or Pythonic approach to solving some problem). But on the
other hand, I really think it's important to match students doing
mathematically difficult (or even just theoretically difficult)
projects with someone who knows as much about the theory as possible,
because they are going to run into issues with the theory at some
point, and it's nice when the mentor can give them help there.

I remember there was a nice example of this with Ondrej and Sean. They
can correct me on the details, but there was some issue with incorrect
results. It was either an issue of a typo in a book or a typo in the
code (I don't remember), but Ondrej helped him figure it out. The
point it, you really had to know the physics to understand the problem
and figure out how to fix it.

On Tue, Feb 12, 2013 at 12:23 PM, Matthew Rocklin <mroc...@gmail.com> wrote:
> I'm happy to serve as secondary mentor on any of {assumptions, matrices,
> stats, rewrite-rules}. I don't think I'm sufficiently on top of things to
> be an effective mentor this year. Let me know if you'd like me on the list.

Sure, add yourself. Backup mentors are helpful, especially for
difficult projects. And of course, we will appreciate any help you
can give reviewing applications.

Aaron Meurer

[Matthew Rocklin]

I like the timeline.  I think that it indirectly measures maturity.

[Sergiu Ivanov]

On Tue, Feb 12, 2013 at 12:16:17PM -0700, Aaron Meurer wrote:
>
> You can still help us review applications. I would not add your name
> to the wiki unless you are actually willing to mentor, so that I can
> see who exactly we have who can mentor people, but when the time comes
> to review applications, let me know if you are interested in helping
> out, and we can add you in.

That's great! I am sure interested in helping you with application
review.

Sergiu

[Aaron Meurer]

I saw your edits to the template, and I mostly like them. One thing
that strikes me as maybe a bit much is the part that says "In your
opinion what are the two most undervalued packages in Python?" (and
also the question before it). I know that I would not have been able
to answer this question when I first applied to GSoC, because my only
Python experience was solving my own problems using the language and
the standard library. Maybe we could change it to something more
Python language related, like "what are your favorite features of
Python that are lacking in most other common programming languages?"
or "what, in your opinion, is the most advanced Python language
feature or standard library functionality that you have used?"

Furthermore, the focus for almost all the projects will not be on
using third party packages, but rather features of the Python
language, standard library, and SymPy.

Also, I wouldn't worry too much on trying to figure out how well the
students know Python in the application. That will come out clear
enough in the patch requirement.

But all in all, I think this is a great idea. This should make reading
the applications fun, and reduce the amount of boilerplate that the
reviewers just skim over anyway.

Aaron Meurer

[Matthew Rocklin]

Please change and improve.  I tend to be pretty liberal with wikis.  

The goal for the question "In your opinion what are the two most undervalued packages in Python?" 

was to serve as an indirect version of "what is your experience with Python?"

I think it is likely to give a far more honest answer and, as you say, should make it more interesting to read.  I agree though that it can be daunting.  Your alternative is far friendlier.

[Aaron Meurer]

On Tue, Feb 12, 2013 at 12:16 PM, Aaron Meurer <asme...@gmail.com> wrote:
> On Mon, Feb 11, 2013 at 11:19 PM, Ondřej Čertík <ondrej...@gmail.com> wrote:
>> On Mon, Feb 11, 2013 at 8:40 PM, Aaron Meurer <asme...@gmail.com> wrote:
>>> It also means that the dates I gave are wrong. The application
>>> deadline is actually March 29 and the application period begins March
>>> 18. That gives us more time than I had originally thought, though we
>>> should still get going on this now, especially with the ideas page,
>>> because now that the program has been officially announced, students
>>> are going to start coming to SymPy and looking at it.
>>
>> Yep. What ideas/projects do you think are high priority (or important) in sympy?
>> Or do you prefer to simply list all good ideas and simply let students choose?
>> I have a few ideas for projects, that I will propose in more detail/guidance,
>> and then we can have just random good ideas where the students can get inspired.
>>
>> Ondrej
>
> As always, I encourage students to apply for those projects that are
> most interesting to them. If it's on the ideas page, then it means
> that we want it implemented (modulo some cleaning up of the ideas page
> as I mentioned earlier), so it's not like we won't accept them because
> they are proposing to do something we don't want. If they want to
> suggest an idea that's not on the ideas page, that's fine, and it
> should be clear after discussing it with us whether we would accept
> the idea or not.
>
> With that being said, I consider these to be the highest priority
> projects (in order, most important first):

I forgot one. This is maybe not enough to be a GSoC project in
itself, though enough could probably be added to it to make it one.
We need to automate our release process (see
http://code.google.com/p/sympy/issues/detail?id=3445, and my rant on
the mailing list linked to there). I would put this at the top of my
list, above the assumptions. Right now, we are releasing at an
abysmal rate (less than once a year), when we have enough changes
coming in to be releasing once a month. I myself have already
committed to not do another release until this is fixed, so unless
someone else steps up, this literally means that we won't release
again until this issue is solved.

Any thoughts on something that could be added to this to make it a
full GSoC project?

Aaron Meurer

[Ondřej Čertík]

On Tue, Feb 12, 2013 at 8:12 PM, Aaron Meurer <asme...@gmail.com> wrote:
[...]

> I forgot one. This is maybe not enough to be a GSoC project in
> itself, though enough could probably be added to it to make it one.
> We need to automate our release process (see
> http://code.google.com/p/sympy/issues/detail?id=3445, and my rant on
> the mailing list linked to there). I would put this at the top of my
> list, above the assumptions. Right now, we are releasing at an
> abysmal rate (less than once a year), when we have enough changes
> coming in to be releasing once a month. I myself have already
> committed to not do another release until this is fixed, so unless
> someone else steps up, this literally means that we won't release
> again until this issue is solved.
>
> Any thoughts on something that could be added to this to make it a
> full GSoC project?

I would not do this as a project, because we don't know yet what works
for us well and we need to keep iterating on this, starting now. See
my comment in the issue #3445 you posted. I just released NumPy 1.7.0,
and I have the process fully automated, so let me create something for
SymPy.
I've recently contributed the following improvements to our Travis-CI testing:

https://github.com/sympy/sympy/pull/1756
https://github.com/sympy/sympy/pull/1758
https://github.com/sympy/sympy/pull/1759

So I think that we are in a pretty good shape here, the last missing
piece is testing our Sphinx docs, which I will try to contribute soon.
We are depending a bit on the actual Travis VM setup, which we can't
influence, so I think it makes sense to run the tests once in our own
well controlled environment in a Vagrant VM during the release
process, as a safety check. I'll contribute the initial version, and
then the release process will be defined by just running a script.
Anybody can improve it by sending a PR.

Ondrej