anonymous reviewing of trac tickets? trac moderators?
Dima Pasechnik
I recently had a rather unpleasant experience reviewing a ticket that
shall remain unnamed. It went as follows. I suggested few
improvements, asked few questions. Some suggestions were implemented,
some plainly ignored, along with questions. I suggested few more
improvements, asked (and repeated) few questions.
The developer grew visibly irritated with each round of exchanges,
saying that he has very little time, that I should basically implement
the fixes I suggest myself, that I do not value his work, that I do
not care about the project in general, then descending at the end into
something bordering on a verbal abuse, even though I gave the ticket a
positive review...
Therefore two suggestions:
1) it would we good to have a "moderator" who can step in in such
cases.
2) eventually, in order to prevent these things getting personal, it
might be good to have a possibility to anonymise reviewing.
Thanks,
Dima
William Stein
> Dear all,
>
> I recently had a rather unpleasant experience reviewing a ticket that
> shall remain unnamed. It went as follows. I suggested few
Given that sentence it is trivial to figure out what ticket you're
talking about:
http://trac.sagemath.org/sage_trac/ticket/8404
It's best if people reading your email can look over the actual
conversation and form their own opinions.
> improvements, asked few questions. Some suggestions were implemented,
> some plainly ignored, along with questions. I suggested few more
> improvements, asked (and repeated) few questions.
>
> The developer grew visibly irritated with each round of exchanges,
> saying that he has very little time, that I should basically implement
> the fixes I suggest myself, that I do not value his work, that I do
> not care about the project in general, then descending at the end into
> something bordering on a verbal abuse, even though I gave the ticket a
> positive review...
>
> Therefore two suggestions:
>
> 1) it would we good to have a "moderator" who can step in in such
> cases.
>
> 2) eventually, in order to prevent these things getting personal, it
> might be good to have a possibility to anonymise reviewing.
>
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've personally been unintentionally rude many times in
the context of Sage, but I (usually) apologize.
-- William
Alex Ghitza
> 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.
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.
And please keep in mind that any single word communicated electronically
can be interpreted along a large range of meanings, in the absence of
other factors such as body language, tone of voice, facial expression;
smileys are not always enough to bridge the gap. So, as Minh pointed out,
it is *extremely* easy to misinterpret innocent jokes or comments.
Best,
Alex
--
Alex Ghitza -- http://aghitza.org/
Lecturer in Mathematics -- The University of Melbourne -- Australia
Robert Bradshaw
> On Thu, 11 Mar 2010 18:42:00 +1100, Minh Nguyen
> <nguye...@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
Dima Pasechnik
On Mar 11, 3:42 pm, Minh Nguyen <nguyenmi...@gmail.com> wrote:
> Hi Dima,
>
> On Thu, Mar 11, 2010 at 5:10 PM, Dima Pasechnik <dimp...@gmail.com> wrote:
>
> <SNIP>
>
[...]
>
> First, it is very frustrating that one has to rebase and rework a
> patch multiple times. A case in point is the situation with the
> Sage-Combinat team, whose members need to rebase their patches after
> each Sage release. I can assure you that such a task is very tedious,
> more so when the Sage-Combinat team has a huge patch queue that totals
> to a few megabytes in size. In most cases, just doing such a rebase
> takes up all of one's energy and time for a few days.
I believe that Nathann has been shooting himself in the foot multiple
times by not reading carefully what I suggested, and as a result he
had to do more iterations than it was needed.
Actually, two of these changes were trivially doable by editing the
patch file directly, so I really do not see
the base for complaints that it took long time...
>
> Second, in most cases, the author of a patch is the only person who
> understands the algorithm implemented. It can be difficult for someone
> to review or indeed to find a reviewer. In the current situation, many
> of ncohen's graph theory tickets that need reviews have been in that
> state for a long time and no one has had time to do the review. Added
> to that is the fact that his linear programming tickets have also been
> in such a state. I do sense his frustration. I for one have time, but
> not the expertise, so I started a textbook project both to document
> the graph theory module and to learn enough background materials to
> review tickets relating to graph theory.
I, for one, do have expertise (and even a publication record, so
Nathann could have checked whether my opinion is enlightened enough,
IMHO) in graph algorithms and optimization, and I even have enough
time lately to review some tickets on this...
But, given the recent experience, I am not sure if I want to touch
Nathann's tickets any more.
I can try...
>
> 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.
well, this might be time-consuming for a reviewer. I view reviewing to
an extent like reviewing a
scientific publication --- so I suggested to add few more examples,
that would moreover ring
the bell to anyone who saw the classical Kuratovski theorem on planar
graphs, and given that
I am not really familiar with the graph functionality in Sage would be
best done by the
author. Without these examples it was difficult to evaluate the
usefulness of the code, as I tried to explain.
Moreover, experience with my own trac tickets was such that I was left
to fix things myself (as I duly did, without accusing anyone of being
rude to me),
so I assumed that this is downright normal to ask to rework things
many times!
Just look at
http://trac.sagemath.org/sage_trac/ticket/8150
http://trac.sagemath.org/sage_trac/ticket/8076
[...]
Best,
Dima
Dr. David Kirkby
> On Mar 11, 2010, at 12:04 AM, Alex Ghitza wrote:
>
>> On Thu, 11 Mar 2010 18:42:00 +1100, Minh Nguyen
>> <nguye...@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).
I agree with Robert there. It is better the code is committed with issues
resolved, rather than leave them for a later date.
> 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.
Obviously.
>
> - Robert
>
Dave
Dr. David Kirkby
> Hi Dima,
>> 2) eventually, in order to prevent these things getting personal, it
>> might be good to have a possibility to anonymise reviewing.
>
> Most of the time, reviewers are also people who contribute a lot to
> improving a patch. We don't want make such contributors anonymous, but
> instead to properly credit their ideas, contributions, patches. With
> reviewers listed on tickets, I think this encourages them to be more
> careful and thorough in their reviews.
>
I understand Dima's frustration. I think if he feels someone is being
rude/uncooperative, then it is better to take no further part in the review
process. Let someone else take the responsibility for approval. I have in one
such case asked that my name is not added to the "Reviewer" list, as I do not
want it recorded that I gave a positive review to something I feel does not
warrant it.
It is somewhat embarrassing when you give a positive review to a patch that you
later find out should not have been given that positive review, because it is
flawed in some way. Hence there is a motivation to ensure one is thorough in
reviewing the ticket.
If the review process was to become anonymous, then the I believe the quality
of reviews would drop.
Dave
Dr. David Kirkby
> On Thu, 11 Mar 2010 18:42:00 +1100, Minh Nguyen <nguye...@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.
>
> 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.
> Best,
> Alex
I believe however that authors should not expect this. I recently had someone
give me a positive review subject to some trivial grammar and spelling errors. I
have no problem with that. Why should the reviewer correct my grammar or spelling?
One obvious exception would be if the grammar of someone is poor, as English is
not their first language. Then it is much more helpful for the reviewer to make
a reviewer patch.
I think we need to avoid the situation where someone presents sub-standard work,
then expects the reviewer to correct it.
Nathann Cohen
I do not know how whether I have my place in this discussion...
Several words, though.
I know I did not take very well one of your first messages, and I
progressively got the impression you were showing contempt toward this
work. Well, perhaps this word is not the best one, and I totally agree
with Robert when he mentions native speakers. This may have mattered.
Your first message was actually a request to change LP to MIP or MILP.
I know I very often do this, which is what you may call a mistake,
though as the difference between LP and MILP can always be deduced
from the context (or from the complexity of the problem mentionned), I
often forget it.
Well, I do not mind changing it, though I take it more as a stylistic
custom than something really important.
Actually, this patch being an algorithm for the H-minor problem, whose
review I expected to be long and tedious, I did not expect to receive
as a first comment a request to fix a typo. You also mentionned the
slowness of the algorith, which I had mentionned previously :
I understand this implementation is in many cases impractical, but I
thought odd that you would mention yourself its slowness even before
having tested it. I would have taken your remark much more differently
if you had only said "I tried to find this minor on this graph, and it
took me 3 hours", or given examples of running times. You did not
mention this, and I got the impression you were criticizing the
slowness without having even tested it yourself, just to check. I
still do not know whether you did, only you know as you did not
explicitely mention it.
Saying, just after this, that depending on its slowness it may be
useless to work on including this in Sage was a bit to aggressive for
me, when I had no proof you had not just taken a quick look at it.
Then again, english is not my native language, nor do I know what you
really meant in the end. This is just how I understood your message.
Later, you mentionned it may not scale, and I agreed with you, and you
sent another request :
"can you test it on 20-25 vertices ?"
I am sorry to have to say this, but I can obviously do it. As easily
as you would. It takes one line of Sage, namely ::
sage : graphs.RandomGraph(30, .3).minor(graphs.CompleteGraph(5))
Or something alike. As communications on the Trac server, because of
differences in our timezones, can sometimes take several hours, I
found a bit odd to be asked to type just one command, when you can
have done it yourself and obtained the answer immediately. It is a bit
like that when one is asked several times questions that are included
in the manual. I do not mind answering them, but at some point one is
expected to try by oneself. This also gave me the impression you still
had not applied and tested the patch, which confirmed what I already
thought of your first comments...
You also said "(by the way, "no K_4-minor" is equivalent to "treewidth
at most 2", so you can write another short function to test fro just
this...)". I think this is the place where, as Alex mentions it, a
reviewer is welcome to add a reviewer's patch. Very often, when
reviewing patches, I notice many small things that would take much
time to be explained over a Trac ticker, but which can be fixed in
several seconds by a short patch, none of which can really be
"refused" by the original author. It can come from fixing typoes to
adding an example in the docstrings, but in this situation it would
have required to add a very short function -- a one-liner. I would
have greatly appreciated to see you wrote a small patch based on mine
just to add a one-liner. It may not be long to do, but it is a perfect
proof to show in interest in the work being done. It is also a way to
quickly add a function to Sage when you find it useful and relevant.
Some time later, after these exchanges, you set the ticket to positive
review. I had, until then, absolutely no proof that you had read the
code. Actually, I hinted that you had not even applied the patch, and
none of your remarks had focused on the code.
I hope you will not think I did not invest time in the review process.
In this very ticket, I was asked to write a document explaining the LP
formulation better than the comments in the code would have, and I did
it. You can almost think I wrote a 8-pages long LaTeX document just
because of this very review. It took me -- a lot -- of time. Actually
longer than the time it took me to write the actual patch, when I
think about it.
Until now, I still do not know whether you read it, which was the
whole point of writing it.
I also read the following line from you :
////
Please fix this, otherwise I'll have to revert to "needs work" :) (I
wish I had such an efficient means to make my students work hard :))
////
Well, I now know you are not a PhD student. I am. I do not mind
working hard, I quite like both my job and the science I study, but I
take very badly the custom of some researchers to consider PhD student
as some unexpectedly useful form of animal life. One does not *make*
students work hard. One *asks* them. They can quit whenever they want,
this is the difference between them and slaves.
I said much more than "a few words", in the end. I will stop here as
it is the place where I have to apologize. I wrote all this to try to
make our misunderstanding clear, but I know that at some point I could
have avoided our conversation to lead a bit too far, which I failed to
do. So I apologize.
About the propositions you made, and I hope you will consider my
opinion as kindly as you would consider the opinion of any other, I do
not think anonymous reviewing would help. We're working together, and
there is nothing to earn by working on a free software. We are just
trying to build something together. Even if some, like me, sometimes
forget we have no reason at all to fight each other as we are all
working in the same direction, I believe as William said it that we
are the ones at fault.
With anonymous reviewers, the quality of review, and the whole
interest of working together would disappear.
Please receive my apologies, once more.
Nathann Cohen
Dima Pasechnik
Thanks for the message.
On Mar 11, 8:11 pm, Nathann Cohen <nathann.co...@gmail.com> wrote:
> Hello !
>
> I do not know how whether I have my place in this discussion...
> Several words, though.
>
> I know I did not take very well one of your first messages, and I
> progressively got the impression you were showing contempt toward this
> work. Well, perhaps this word is not the best one, and I totally agree
> with Robert when he mentions native speakers. This may have mattered.
>
> Your first message was actually a request to change LP to MIP or MILP.
> I know I very often do this, which is what you may call a mistake,
> though as the difference between LP and MILP can always be deduced
> from the context (or from the complexity of the problem mentionned), I
> often forget it.
> Well, I do not mind changing it, though I take it more as a stylistic
> custom than something really important.
You might, but a casual reader of that can be easily misled.
>
> Actually, this patch being an algorithm for the H-minor problem, whose
> review I expected to be long and tedious, I did not expect to receive
> as a first comment a request to fix a typo. You also mentionned the
> slowness of the algorith, which I had mentionned previously :
> I understand this implementation is in many cases impractical, but I
> thought odd that you would mention yourself its slowness even before
> having tested it. I would have taken your remark much more differently
> if you had only said "I tried to find this minor on this graph, and it
> took me 3 hours", or given examples of running times. You did not
> mention this, and I got the impression you were criticizing the
> slowness without having even tested it yourself, just to check. I
> still do not know whether you did, only you know as you did not
> explicitely mention it.
Adding code to a public project is akin to publishing. You have to
"sell" your code
sufficiently, to take away doubts that it works on toy examples,
right?
> Saying, just after this, that depending on its slowness it may be
> useless to work on including this in Sage was a bit to aggressive for
> me, when I had no proof you had not just taken a quick look at it.
> Then again, english is not my native language, nor do I know what you
> really meant in the end. This is just how I understood your message.
>
> Later, you mentionned it may not scale, and I agreed with you, and you
> sent another request :
>
> "can you test it on 20-25 vertices ?"
>
> I am sorry to have to say this, but I can obviously do it. As easily
> as you would. It takes one line of Sage, namely ::
>
> sage : graphs.RandomGraph(30, .3).minor(graphs.CompleteGraph(5))
>
> Or something alike.
that's not what I would consider testing --- running something like
this in a loop, taking time, perhaps,
yes.
> As communications on the Trac server, because of
> differences in our timezones, can sometimes take several hours, I
> found a bit odd to be asked to type just one command, when you can
> have done it yourself and obtained the answer immediately. It is a bit
> like that when one is asked several times questions that are included
> in the manual. I do not mind answering them, but at some point one is
> expected to try by oneself. This also gave me the impression you still
> had not applied and tested the patch, which confirmed what I already
> thought of your first comments...
>
> You also said "(by the way, "no K_4-minor" is equivalent to "treewidth
> at most 2", so you can write another short function to test fro just
> this...)". I think this is the place where, as Alex mentions it, a
> reviewer is welcome to add a reviewer's patch.
well, "you can" did not mean "you must"... It was just an offhand
remark, that it might be a useful application of your code, especially
as I recalled you taking about coding a treewidth computation.
> Very often, when
> reviewing patches, I notice many small things that would take much
> time to be explained over a Trac ticker, but which can be fixed in
> several seconds by a short patch, none of which can really be
> "refused" by the original author. It can come from fixing typoes to
> adding an example in the docstrings, but in this situation it would
> have required to add a very short function -- a one-liner. I would
> have greatly appreciated to see you wrote a small patch based on mine
> just to add a one-liner. It may not be long to do, but it is a perfect
> proof to show in interest in the work being done. It is also a way to
> quickly add a function to Sage when you find it useful and relevant.
>
> Some time later, after these exchanges, you set the ticket to positive
> review. I had, until then, absolutely no proof that you had read the
> code. Actually, I hinted that you had not even applied the patch, and
> none of your remarks had focused on the code.
well, I did not take that hint lightly --- I can be lazy sometimes,
but not THAT lazy and careless, you know...
>
> I hope you will not think I did not invest time in the review process.
> In this very ticket, I was asked to write a document explaining the LP
> formulation better than the comments in the code would have, and I did
> it. You can almost think I wrote a 8-pages long LaTeX document just
> because of this very review. It took me -- a lot -- of time. Actually
> longer than the time it took me to write the actual patch, when I
> think about it.
>
> Until now, I still do not know whether you read it, which was the
> whole point of writing it.
No, I didn't really --- but I didn't ask for it, either. Jason and
David (Joyner) did ask for it, not me...
>
> I also read the following line from you :
>
> ////
> Please fix this, otherwise I'll have to revert to "needs work" :)
by the way it was 2nd time I had to point out that terminology must be
fixed, sorry...
> (I
> wish I had such an efficient means to make my students work hard :))
> ////
>
> Well, I now know you are not a PhD student. I am.
I wrote "students", not "PhD students". I also have undergraduates to
teach, and, gosh, 99% of them are lazy as hell...
> I do not mind
> working hard, I quite like both my job and the science I study, but I
> take very badly the custom of some researchers to consider PhD student
> as some unexpectedly useful form of animal life. One does not *make*
> students work hard. One *asks* them. They can quit whenever they want,
> this is the difference between them and slaves.
I happen to have wonderful PhD students, and I treat them with full
respect, I must assure you.
And I even fix, myself, English in their LaTeX files...
And, like you, I hate these PhD supervisors who are slave drivers, who
insist that their names are always added on the lists of authors of
whatever their PhD students publish, etc...
Having said that, it's part of a teacher's job to make students work,
there isn't anything wrong with this.
Student's work is to learn, and learning is not always pleasant (and,
indeed, they can quit, anyway, unlike slaves). Or they can fail many
exams and be expelled for this...
But it's part of the thing: "no pain, no gain" applies not only to
sport, but to gaining knowledge, too.
Students should not assume that by virtue of being admitted to a
university they will get their diploma...
(OK, I got carried away here...)
>
> I said much more than "a few words", in the end. I will stop here as
> it is the place where I have to apologize. I wrote all this to try to
> make our misunderstanding clear, but I know that at some point I could
> have avoided our conversation to lead a bit too far, which I failed to
> do. So I apologize.
>
> About the propositions you made, and I hope you will consider my
> opinion as kindly as you would consider the opinion of any other, I do
> not think anonymous reviewing would help. We're working together, and
you know, it did start up, for me, as a joke, a suggestion of having
anonymous reviewing.
But it went so far that it got very real. :-)
> there is nothing to earn by working on a free software. We are just
> trying to build something together. Even if some, like me, sometimes
> forget we have no reason at all to fight each other as we are all
> working in the same direction, I believe as William said it that we
> are the ones at fault.
>
> With anonymous reviewers, the quality of review, and the whole
> interest of working together would disappear.
>
> Please receive my apologies, once more.
Received and accepted, no problem...
I'll review some more of your tickets then (so please don't get mad at
me if I will again insist on "mixed integer" all over the place). I
also plan to submit an implementation of computing Lovasz theta-
function of a graph, and some of its relatives, and you'll be most
welcome to review these.
Dmitrii
>
> Nathann Cohen
Jason Grout
> I
> also plan to submit an implementation of computing Lovasz theta-
> function of a graph, and some of its relatives
Thanks! I would find this useful.
Jason
Florent Hivert
While you are at it,
>> 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 believe however that authors should not expect this. I recently had
> someone give me a positive review subject to some trivial grammar and
> spelling errors. I have no problem with that. Why should the reviewer
> correct my grammar or spelling?
>
> One obvious exception would be if the grammar of someone is poor, as
> English is not their first language. Then it is much more helpful for the
> reviewer to make a reviewer patch.
I don't known exactly how to solve it, but I'm sure there are several non
native speaker (at least I can easily imagine two, I'm one of them) which are
reviewing each other patch, and whose English is quite poor. So probably, we
let huge English mistakes pass. In several occasion, I had wanted someone to
reread a patch only for the English, but let it pass, mostly because the show
must go on, and that I don't want do take other time...
Anyway I'm even not sure that working on patch is a good way... Indeed having
an overall view on the file is certainly much better. So my idea is the
following (as you probably have guessed, I'm giving some more work to other
people while I'm sure not to be qualified to do the job :-)):
What do you think about some more or less organized systematic rereading of
the doc ? I mean make a ticket listing the file one by one marked them as
reread by a native as things move on. Should this project have a low
priority ? I realize that adding doctests should be much more important.
Any comment ?
Cheers,
Florent, improving his English (or at least trying to do so).
>
> I think we need to avoid the situation where someone presents sub-standard
> work, then expects the reviewer to correct it.
>
>
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
--
Florent Hivert
---
Il y a trois sortes de gens dans le monde : ceux qui savent compter et
ceux qui ne savent pas.
There are three kinds of people in the world: those who can count,
and those who cannot.
---
Professeur, Coordinateur �quipe Combinatoire et Algorithmes
Laboratoire d'Informatique, de Traitement de l'Information
et des Syst�mes (EA 4108)
Bureau U2.2.11 -- Campus du Madrillet
Universit� de Rouen -- Facult� des Sciences et des Techniques
Avenue de l'universit� -- 76801 SAINT ETIENNE DU ROUVRAY
T�l. : 02.32.95.52.91 -- Fax : 02.32.95.51.87
M�l. : Florent...@univ-rouen.fr
Robert Bradshaw
I wouldn't hesitate to ask for a quick proofreading review if you
think one is warranted.
> Anyway I'm even not sure that working on patch is a good way...
> Indeed having
> an overall view on the file is certainly much better. So my idea is
> the
> following (as you probably have guessed, I'm giving some more work
> to other
> people while I'm sure not to be qualified to do the job :-)):
>
> What do you think about some more or less organized systematic
> rereading of
> the doc ? I mean make a ticket listing the file one by one marked
> them as
> reread by a native as things move on. Should this project have a low
> priority ? I realize that adding doctests should be much more
> important.
>
> Any comment ?
I know that Minh has done an excellent job of this for large parts of
the Sage documentation already. Personally, though I'm a native
English speaker, I'm not that skilled of a proofreader. I don't think
anything systematic is needed, people can continue to contribute as
their skills and time allow.
- Robert