On Wed, May 28, 2014 at 3:30 PM, Paul-Olivier Dehaye
<paul-olivier.deh...@math.uzh.ch> wrote:
> Again, in the big wave of emails, this one also got misdirected:
>
> Hi everyone,
>
> I am looking for people who want to help me, in one way or another, bring
> hundreds of new first time contributors to sage. If I do not find enough
> partners, I will look for other more suitable python-based projects.
>
> The idea would be quite simple: teach python programming around some
> mathematics (such as combinatorics) and simultaneously produce code that
> would be useful for research and worth including in sage. Two catches:
> students are given individual problems to work on, and the course is taught
> on Coursera. Motivation for the students would come in various ways:
> internships, for instance. Quality of the code would be ensured by
> peer-testing the programs.
>
> If you do not know what Coursera or MOOCs are, you are welcome to take my
> upcoming course
> https://class.coursera.org/massiveteaching-001
>
> If you are interested to play with a MOOC platform yourself, you might want
> first to watch the videostream of the 2pm-3pm slot of this conference I am
> co-organising on Tuesday:
> tinyurl.com/openedx-zurich
> as it will help you assess the technical challenges.
>
> I am looking at a start date for the course of around October-November, and
> to bring the discussion off the mailing list (to private) so as to keep an
> element of surprise for the students.
An obstruction to getting code contributions from "hundreds of new
developers" into Sage is the Sage development process via trac, as
documented in the Sage Developers guide. I have 40 students in my
class this quarter, and have encouraged them all to make contributions
to Sage via the standard trac process. Maybe 2 have succeeded, and
when I point them out the documentation and look at it myself, I
wince. This is not to say that the process is bad -- in fact, for
people making major contributions over time, our current system is
pretty reasonable overall, and in some ways quite good. But for
somebody new to software development who wants to make a few small
contributions, e.g., add an example to a docstring, it is not
definitely optimal.
One possible approach for your course would be to do everything
through pull requests on github, which are ridiculously easy to make.
Then we (i.e., some expert sage developers) would aggregate some of
those contributions into a smaller number of trac tickets, which would
get included in Sage in the traditional way. This approach would be
nice since it wouldn't require changing anything about Sage
development or infrastructure, but would allow us to try out new
approaches, which might later influence the Sage development process.
It would be interesting to think about "low hanging fruit" sage
development projects. There's a *ton* of obvious things one might
want to implement for Sage... which are now already done well. E.g.,
I had students in my class tell me what they wanted to do their final
projects on, and in the majority of cases I had to point out that what
they wanted to do was already done in Sage well (or at least done many
times over well in Python). They often still did the projects, but
making it clear that it was for-fun toy code. However, one example
is applying transforms to a 2d plot in Sage -- that seems not done,
though we have 3d transforms in Sage. I know trac is supposed to
have "beginning tickets", but when I send beginners to trac, they
invariably claim to find nothing to do. So a big list of low hanging
fruit that would make sense to implement in Sage would be useful.
Again, an example is:
- implement functions like rotate, translate, etc., for 2d
graphics objects, like the corresponding 3d functions.
That said, Sage is getting mature enough at the easy things that I
wouldn't be surprised if somebody responds to this email and says --
oh, that's easy, via converting the plot to matplotlib, or
something...
Of course when I think about more advanced mathematics, Sage has a
million obvious gaps to fill, and is extremely immature with a huge
amount of low hanging fruit. But this is all grad student level
stuff.
-- William
>
> Let me know!
>
> Paul
>
> Paul-Olivier Dehaye
> SNF Professor of Mathematics
> University of Zurich
> skype: lokami_lokami (preferred)
> phone: +41 76 407 57 96
> chat: pauloliv...@gmail.com
> twitter: podehaye
> freenode irc: pdehaye
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-combinat-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-combinat-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-combinat-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-combinat-devel.
> For more options, visit https://groups.google.com/d/optout.
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.
