Hi Alex,
On Mon, Mar 16, 2009 at 12:04:37PM +1100, Alex Ghitza wrote:
> Hi,
>
> On Mon, Mar 16, 2009 at 10:19 AM, Minh Nguyen <nguyenmi...@gmail.com>
> wrote:
>
> On the above site, I notice the following dot point:
>
> "credit: young people, publication record"
>
> I'm not sure why this point would be under the list of things that
> disturb anyone about the direction in which Sage is going. Perhaps I
> don't understand the list heading correctly. Is it possible that
> someone please explain that point?
>
> This is a complaint about contributing to mathematical software in
> general, and it's not specific to Sage.A The point of it was this: at
> least in North America, it is difficult for an academic who contributes to
> mathematical software to receive academic credit for it; that is, if
> someone is applying for academic jobs, or going up for tenure, or applying
> for promotion, there is basically no way for the person's contributions to
> math software to be taken into account.A This is quite critical for
> graduate students or postdocs applying for jobs, or for tenure-track
> people trying to make sure they'll get tenure.
>
> It is a tricky point, not sufficiently understood, and over which
> mathematicians tend to disagree.A It is also hard to classify: if I write
> functions for computing with surfaces in 3-dimensions in Sage, this could
> be considered research (if I have to come up with some clever algorithm
> for doing it) or service to the community (others can use these functions
> in their research or for teaching).A What if I just take code that's
> already there but I clean it up and document it better and extend it and
> make it more usable?A It is very easy for someone to say: "That's not
> really doing mathematics." (this is an actual quote)
>
> The emphasis in judging someone's record in academia is on research output
> (in terms of quality and quantity of their publications) and/or their
> teaching credentials.A Writing software falls in an ill-defined gray
> area, no matter how useful this is for the community at large.A I don't
> see this changing drastically in the near future, but hopefully we can
> help build up more awareness and appreciation of it.A A few ways of doing
> this were discussed at SD14: emphasising the referee process for inclusion
> of code into Sage, having a journal associated with Sage, finding out what
> mechanisms are in place in countries that try to deal with this problem (I
> think France was given as an example).
I don't think there is a big difference in the way this is handled in
France. Except for one thing: we get tenure either early, or not at
all (they would like to change this, which is part of the reasons for
the current strikes, but that's another discussion). So if and once
you are in, you can take much more risks, and invest in the long
run. I would never have started MuPAD-Combinat otherwise. It killed my
file for the first years, and is finally starting to pay off "by
reputation". Well, I'll tell you more about this after my upcoming
interviews :-)
So, my personal approach to this (for my "students" and myself) is
that every line of code/doc/tests should be written with a long term
aim, but also for a specific short term research goal of the developer
*himself*. This to ensure that his efforts get at least rewarded by
the publications for this research (and/or by having learned something
useful in the process).
Of course I am not certainly claiming that this is always
possible. All I can say is that, so far, we essentially managed to
follow this guideline with MuPAD-Combinat. What helped is that we work
a lot in teams in our field, so if you don't document and test well
your code, your teammate won't be able to use it. Another side effect
is that the code is written by its users, which puts some guarantees
on its usability.
But yes, this means that the least research-related parts ought to be
coded not by the grad students, but by the tenure faculty.
Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" <nthi...@users.sf.net>
http://Nicolas.Thiery.name/
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
