On Thu, May 29, 2014 at 8:49 AM, kcrisman <kcris...@gmail.com> wrote:
> 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.

+1

> 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.

Though I wouldn't expect everyone to end up with a workable
contribution, it's not a stretch to expect at least a handful of
ready-to-incorporate improvements.

> 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.

There is so much bureaucracy. I just keep thinking back to the "22
easy steps to contribute to Sage."

> 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.

I think that's because we took our trac-based (and patch-based)
workflow and just plugged git in. I don't know if we want to open this
discussion now, but it's certainly worth revisiting (starting with
defining what our goals are rather than what our tools are). But now
that we're on git a pull request is 99% of what a ticket is
(specifically, an annotated point to a particular git branch/commit
that needs review) and we should seriously consider accepting that
format for contributions.

> 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.

-- 
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.

Reply via email to