39

I have been using an econometrics toolbox for around 2 years and it is great, very useful. It is available from someone's personal website.

I have found a mistake in one piece of code which has set me back for a considerable amount of time. It is a small change but with vast consequences. Instead of questioning the code, I did my idea.

Now that I have found the problem, what is the protocol for highlighting this? Is emailing the author necessary?

Improve this question
13
  • 63
    Is it available on github/bitbucket? If so, just make an issue or even better fork and submit at pull request.
    – Akavall
    Jul 18, 2019 at 16:00
  • 10
    Although it can be rude to point out others' mistakes in general, when it comes to code, it is much appreciated.
    – Evorlor
    Jul 19, 2019 at 3:45
  • 5
    @Evorlor How can pointing out mistakes be rude? That's how we learn.
    – user2768
    Jul 19, 2019 at 7:40
  • 5
    @user2768 It can be phrased in a rude way, or same people take offence even if it is phrased nicely.
    – gerrit
    Jul 19, 2019 at 8:00
  • 3
    Obligatory xkcd: xkcd.com/386
    – R.. GitHub STOP HELPING ICE
    Jul 20, 2019 at 3:37

6 Answers 6

Reset to default
74

Now that I have found the problem what is the protocol for highlighting this, is emailing the author necessary?

It isn't necessary, but it is the right thing to do, if you don't, you're responsible for causing others set backs that will waste them a considerable amount of time.

Improve this answer
18
  • 29
    @user30609 Don't overthink this, the email just needs to say something along the lines of: Dear A, I have been using your econometrics toolbox for around 2 years and it has been very useful for my work. <<Optionally mention some of your work, possibly wrapped in parenthesis.>> Recently I discovered a small mistake in the code: <<describe mistake (and fix if known)>>. Perhaps you can implement this fix and include it in your toolbox; it would save others the frustration of debugging for hours.
    – user2768
    Jul 18, 2019 at 8:32
  • 59
    Coders love free fixes to their code. The two times I notified the coders and supplied the fix along with the e-mail, it got deployed within 24 hours.
    – Nelson
    Jul 18, 2019 at 15:49
  • 7
    @Nelson Coders ... probably. But let's be be honest: There's lots of PANTA code in academics (Publish And Never Touch Again). One could play devil's advocate and say: If they were interested in maintaining the code, then they'd put it on a public SCM, and not only offer some ZIP on a personal website. But it's worth a try, of course: The worst thing that can happen is that the message is ignored...
    – Marco13
    Jul 18, 2019 at 17:30
  • 14
    @MonkeyZeus I've never got this. Why is it rude to point out a mistake, when it's a mistake? Everybody makes mistakes. It's clearer to say it's a mistake that needs fixing, instead of "overcame a hurdle" which would take me a while to parse. Isn't wasting time ruder than bluntness?
    – wizzwizz4
    Jul 18, 2019 at 20:45
  • 4
    @user2768 I don't think I can agree with this. I would not blame someone for not going out of their way to possibly help strangers, where he doesn't even know if they want or need help and if the author actually cares. I think it is a nice thing to do and would also do it myself, but I would never blame someone for not doing it - I don't see it as a duty which needs to be done, but rather a good act which one might do if he wants to do something nice.
    – Falco
    Jul 19, 2019 at 13:37
53

An important point of etiquette that has been skipped in the other answers:

Treat it as a suspected bug, and do not assume "I'm right, you're wrong" while presenting your fix.

  • No matter how confident you are on the matter, there is always room for having misinterpreted or overlooked something important.

Consider the case of finding an 'error' in code of: 

(A + B)

And you decide that all of your use cases need this to be:

ABS(A + B)

Your use cases may not include a need for that possible negative to exist, or even be able to handle it when it does, but that does not mean cases outside of your consideration may not require them.

  • Start off with the assumption that the original coders know more about the code than you do. [They might not actually, but opinions of others can always be re-evaluated...]
  • Approach it as having a goal of mutually gaining a better understanding of what the code is doing, and what it should be doing, and how it is actually being used.
  • Consider phrasing any suggestions for changes/improvements as questions rather than commands. ["Do you see any flaws in my attempt at fixing my problem?" vs "You should use my code instead."]
Improve this answer
9
  • 5
    Totally agree!!
    – user30609
    Jul 19, 2019 at 8:02
  • The OP writes, I have found a mistake in one piece of code, so this doesn't really answer the question, it questions the legitimacy of the question and answers a different one.
    – user2768
    Jul 19, 2019 at 14:02
  • 13
    @user2768 - They Think they have found a mistake, and they probably have, and they asked for a protocol on how best to handle it. Part of the proper protocol is to leave the door wide open to the possibility that you are in fact wrong about the nature of the mistake you've found... If you think this answers 'a different question', then you've entirely missed the point of the answer.
    – TheLuckless
    Jul 19, 2019 at 15:57
  • 12
    @user2768 no matter how much one 'really knows' about a software bug, proper etiquette is to still assume you might be wrong, no matter how sure you are that you're right. It is the polite standing to start out such a conversation on, and covers your backside if you do actually overlook something. - Also don't forget that it is also entirely possible for BOTH parties to be wrong. Bugs in code and design aren't exactly uncommon...
    – TheLuckless
    Jul 19, 2019 at 16:29
  • 4
    @emory: Humans are not robots. We are far more willing to listen to "Can you help me understand X?" instead of "X is why you are wrong." It's a matter of tact, nothing more.
    – Kevin
    Jul 20, 2019 at 19:30
7

You have 3 possibilities:

  1. Contact the author as per the other answer. Best option based on the subsequent comments revealing that the source was a personal website.

If the code was published in an article or paper then the following may be applicable:

  1. Contact the editor.

  2. Publish a paper showing your work to improve the usefulness of the code.

The third depends on the type of error and how it was corrected - if it meant changing a 3 to 5 then that is trivial, but if it meant re-coding a significant portion with an extra process then it may well be a suitable option.

You have to tell somehow though.

Improve this answer
9
  • 18
    I'll just add that if the code is on some online repository (e.g. GitHub) then there's a standard way of doing this.
    – Spark
    Jul 18, 2019 at 8:22
  • It was a small change with vast consequences, I don't think it would warrant a paper, nor would I like to profit off of somebodies misfortunes.
    – user30609
    Jul 18, 2019 at 8:23
  • 2
    @user2768 I had assumed (incorrectly as it turns out) the the OP had got the code from a published paper of some sort. Now it has become clear that it was copied from a personal website that changes the game. Oh, if only all questions were written perfectly so that answers could focus on the correct direction...
    – Solar Mike
    Jul 18, 2019 at 8:43
  • 1
    @user30609 writing a clear question is useful on here, see academia.stackexchange.com/help/how-to-ask
    – Solar Mike
    Jul 18, 2019 at 10:54
  • 1
    Sorry @SolarMike I meant on my behalf, I should have written the question clearly and not assumed that the potential readers knew what I was saying
    – user30609
    Jul 18, 2019 at 10:56
6

If you are the programmer yourself, and this is the open source project, best would be just to submit the pull request if they have the SCM repository. Both software would be fixed and you would get credits.

If not, report the bug, best over they bug database if they have any. Blogging about the issue on some random place makes little sense because it may take forever for the authors to find your comments.

If this is some obsolete team that has no repository and no bug database, may make sense to take over the project.

Improve this answer
4

Many repositories have a file "CONTRIBUTING.md". The file contains guidelines for providing feedback, bug reports or how you open pull requests. (Example 1 , example 2) Other projects have a web page or wiki with a "How to Contribute" section, where you can find this information.

If you don't find any of this, you should write an email with the bug report and ask the repository owner on the following procedure.

Improve this answer
0

I'd just like to point that people are publishing code exactly because they want/expect some bugfixes/improvements. I've sent some fixes in my life (or just reported issues), and they were mostly well received. Even when I was wrong (turned out that compilers have the freedom to interpret "undefined behaviour" in the most liberal way).

So don't be afraid to send a report/patch!

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .