Hi! Thanks again for your thoughtful comments. I see two different issues arising in this thread.
1) Your desire to have a MOOC teaching Python programming around some mathematics, which might end up contributing to Sage. (Or sympy, or numpy, or Gambit, or ...) That sounds awesome. I think the hardest part of doing this is not specifically the ability or knowledge of students, but the realities of getting everyone up to speed on any larger system and contributing without huge amounts of involvement by the instructor/mentor/peer leader/whatever. I am cautiously optimistic that there is plenty to do in Sage, but without some direction it will not end up being useful. For a great example, see Vincent Knight's GSOC project - there are lots of students who could implement some basic game theory stuff by the end of a course like this, but to have it actually play well with the rest of Sage, classes, and fit in with (say) 50 other MOOCers' contributions would tax even the most patient overseer. Which is why having it be a GSOC project is a very good idea. And here is one place I agree with rjf - Raymond is very insightful, but does not have a monopoly on insights regarding open source or software development. If you don't know calculus and Lisp, you can't help with large bits of Maxima (hence Sage), period, no matter how talented otherwise. For me personally, I would have to see a syllabus (however archaic that may seem) and the "typical" intro level for the students, though such a thing probably doesn't exist. Given that MOOC dropout rates are pretty high, and that it will probably be hard to figure out ahead of time what a given student brings to the table, one would need a very large collection of things to look at indeed. Unless one had a far smaller set of carefully selected projects, and then let a few dozen MOOCers at each of them, and then perhaps as a final project had them decide which of these was best... that's just a brainstorm, though. Having given my caveats, I want to reiterate that it sounds awesome, and IS doable, but probably with more work than one thinks. And I'll put my money where my mouth is and volunteer to chat personally at some point this summer regarding some possible projects - though again, it may be surprising just how involved even very simple things end up getting "in production", as I've experienced with some students I've worked with on contributing to Sage. 2) There is a higher burden to development than needs be. This is always true to some extent, of course, but especially for documentation this doesn't have to be the case. William summarized this well. In particular, the git switch was supposedly going to make this sort of contribution easier, but as far as I can tell, it is no easier, and maybe harder, than with the previously workflow. See a postscript for a rant about this. Anyway, this is something that will be an issue for contributing to any longer-term project, I think, in nontrivial ways. - kcrisman -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
