On Mar 11, 2010, at 12:04 AM, Alex Ghitza wrote:
On Thu, 11 Mar 2010 18:42:00 +1100, Minh Nguyen
<nguyenmi...@gmail.com> wrote:
Third, in many cases, one can open a new ticket to improve the
changes
introduced by a patch from an existing ticket. In such cases, I think
one can suggest this option to the patch author and leave it to them
to either incorporate the changes in the current patch, or to open a
new ticket to implement the change.
In my experience, "resolving" issues with a current ticket by opening
a new ticket results in sub-par code getting in--and the motivation to
make improvements drops substantially (meaning the follow-up tickets
can linger for a long time). Of course it depends on the nature of the
suggested changes--it's a good idea to push unimplemented enhancements
off to new tickets, but not defects.
To add a small epsilon to Minh's comments: it is fairly common for a
reviewer to add a small reviewer patch fixing docstrings or adding
some
examples, etc. This could be a good alternative to getting frustrated
with the author for not making these changes himself. I have often
added such a patch, often as a sign of appreciation for the time and
effort the author made already; this is especially important when the
person has indicated that he doesn't have time to pursue the ticket
any
further.
I often make such referee patches myself, and I hope the process of
making small referee patches (like fixing a typo) can be greatly
simplified (ideally even done online). However, I think it's important
to point out that good refereeing is hard work too, and often less
enjoyable than writing the code in the first place (hence harder to
get people to do it). Often the referee is doing a favor, and trying
to get quality code/documentation/examples into Sage--it's not just a
hurdle to jump, it's a chance to improve by getting another
perspective. If neither the author nor referee have the time/
motivation to address the issues, then it must not be that important
and neither can complain that it's the other's "job" to do so, and the
code will sit there until someone who does care enough comes along.
(If the author feels the referee is being too strict, they are welcome
to try to convince someone else to sign off on the code. Conversely,
if an author isn't making changes (or providing suitable
justification), there's no obligation for the referee to pass off what
they see as not-up-to-snuff code.) What keeps the system running
smoothly everyone being willing to go the extra mile, giving the
benefit of the doubt, and being grateful that others do the same for
you.
On Mar 10, 2010, at 10:25 PM, William Stein wrote:
If a contributor to the project is being rude as you describe above,
then *they* are the problem. It would be much better to not have such
abusive people involved in the Sage project, then to have to resort to
anonymous reviews. One rude/abusive/poisonous developer can mean
that we don't have 10 (or even 100!) developers next year.
I think in this particular instance whoever was rude should simply and
humbly apologize. Probably it was an honest mistake in the heat of
the moment.
I strongly agree with this. Misunderstandings (especially with non-
native speakers) compounded with frustration (internal or external)
can easily lead to outright rudeness, even when no offense was
originally intended. I am glad that the community as a whole is civil
enough that something like the above is the exception--let's keep it
that way.
- Robert
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
