Re: [Axiom-developer] axiom: [426] branches/wh-sandbox

[C Y]

--- Gabriel Dos Reis <address@hidden> wrote:

> Put blunt, I think you did a grave act of violence by replacing
> the existing asq.c with the new one witout explicit acknowlegement as
> co-author (which I believe is the correct thing), and  acknowledgment
> section that traces the history of asq.c.

In the interests of keeping this discussion productive, can anyone
point to an established (and insofar as is possible objective) standard
for evaluating when co-authorship credit should be awarded and when an
effort is sufficiently new to warrant sole authorship with a history? 
I don't suppose simply diffing the files and looking for some minimum %
changed would be enough, but is there some relatively objective
criteria that can be established here to avoid friction?
 
I understand credit is something people feel strongly about,
particularly in an academic and open source enviornment, so I think it
would be beneficial to have some policy in this regard.  I suspect this
situation is a bit unique - normally academic papers are not
sufficently direct in lineage to provoke a discussion on whether
authors of previous work should have co-authorship credit in the new. 
If we treat Axiom in this fasion (literate programming and whatnot), I
would say the old pamphlet should be cited in appropriate places in the
new one in academic style (after all, if you want to re-use a graph
from an old paper, say in a thesis, you get and include permission and
then cite the source).  An Axiom journal would be a major asset in this
respect, as new versions of pamphlets could be published in one section
of it and become true citable papers.

It's actually a bit of an interesting problem, because we don't want to
dilute authorship credits to the point of not being useful (which
author do you contact if a work lists twenty, and it turns out sixteen
of them worked only on previous versions and don't know anything about
the new one?)  Even in regular computer science channels, there tends
to be a paper published that doesn't directly involve the source code -
really using the literate programming paradigm (where a paper building
on previous work to produce a better result will not just reference
other work but actually include it as part of the foundation on which
they are building subsequent work, as in this case) seems to introduce
some rather unique problems and deserves some careful consideration
about what practices should be used.

One thought might be to include certain "metadata" in the chunck
structure which could be used to automatically add citations and
credits - if we make an emacs mode (say) that when it reads an Axiom
pamphlet parses the metadata and tracks what is changed - then each
chunck knows who changed it and who didn't, and can automatically
produce citation links on that basis (for example, a code block that
survives unchanged through 4 major pamphlet revisions need only refer
to the original, since that is where it came from.)  Maybe one of the
many source code management systems we have available could even
automate this feature based on commit diffs and who is commiting?  Then
the question of "who wrote what" can be quickly and definitively
answered.  If desirable there could be some "primary authorship"
decided based on how much of the current code is new compared to
previous versions.  Peer review could be used to override abuses of the
system (for example, making unnecessary and trivial changes in enough
parts of the code to claim primary authorship.)

Imperfect ideas I'm sure, but maybe someone else has something better
to suggest?

Cheers,
CY


 
____________________________________________________________________________________
Sucker-punch spam with award-winning protection. 
Try the free Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/features_spam.html