Previous | Contents | Index | Next
This is a guide to providing feedback to the PuTTY development team. It is provided as both a web page on the PuTTY site, and an appendix in the PuTTY manual.
Section B.1 gives some general guidelines for sending any kind of e-mail to the development team. Following sections give more specific guidelines for particular types of e-mail, such as bug reports and feature requests.
The PuTTY development team gets a lot of mail. If you can possibly solve your own problem by reading the manual, reading the FAQ, reading the web site, asking a fellow user, perhaps posting on the newsgroup comp.security.ssh, or some other means, then it would make our lives much easier.
We get so much e-mail that we literally do not have time to answer it all. We regret this, but there's nothing we can do about it. So if you can possibly avoid sending mail to the PuTTY team, we recommend you do so. In particular, support requests (section B.5) are probably better sent to comp.security.ssh or passed to a local expert if possible.
The PuTTY contact email address is a private mailing list containing four or five core developers. Don't be put off by it being a mailing list: if you need to send confidential data as part of a bug report, you can trust the people on the list to respect that confidence. Also, the archives aren't publicly available, so you shouldn't be letting yourself in for any spam by sending us mail.
Please use a meaningful subject line on your message. We get a lot of mail, and it's hard to find the message we're looking for if they all have subject lines like ‘PuTTY bug’.
Since the PuTTY contact address is a mailing list, e-mails larger than 40Kb will be held for inspection by the list administrator, and will not be allowed through unless they really appear to be worth their large size.
If you are considering sending any kind of large data file to the PuTTY team, it's almost always a bad idea, or at the very least it would be better to ask us first whether we actually need the file. Alternatively, you could put the file on a web site and just send us the URL; that way, we don't have to download it unless we decide we actually need it, and only one of us needs to download it instead of it being automatically copied to all the developers.
Some people like to send mail in MS Word format. Please don't send us bug reports, or any other mail, as a Word document. Word documents are roughly fifty times larger than writing the same report in plain text. In addition, most of the PuTTY team read their e-mail on Unix machines, so copying the file to a Windows box to run Word is very inconvenient. Not only that, but several of us don't even have a copy of Word!
Some people like to send us screen shots when demonstrating a problem. Please don't do this without checking with us first - we almost never actually need the information in the screen shot. Sending a screen shot of an error box is almost certainly unnecessary when you could just tell us in plain text what the error was. (On some versions of Windows, pressing Ctrl-C when the error box is displayed will copy the text of the message to the clipboard.) Sending a full-screen shot is occasionally useful, but it's probably still wise to check whether we need it before sending it.
If you must mail a screen shot, don't send it as a .BMP file. BMPs have no compression and they are much larger than other image formats such as PNG, TIFF and GIF. Convert the file to a properly compressed image format before sending it.
Please don't mail us executables, at all. Our mail server blocks all incoming e-mail containing executables, as a defence against the vast numbers of e-mail viruses we receive every day. If you mail us an executable, it will just bounce.
If you have made a tiny modification to the PuTTY code, please send us a patch to the source code if possible, rather than sending us a huge .ZIP file containing the complete sources plus your modification. If you've only changed 10 lines, we'd prefer to receive a mail that's 30 lines long than one containing multiple megabytes of data we already have.
If you think you have found a bug in PuTTY, your first steps should be:
If none of those options solved your problem, and you still need to report a bug to us, it is useful if you include some general information:
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html is an article on how to report bugs effectively in general. If your bug report is particularly unclear, we may ask you to go away, read this article, and then report the bug again.
It is reasonable to report bugs in PuTTY's documentation, if you think the documentation is unclear or unhelpful. But we do need to be given exact details of what you think the documentation has failed to tell you, or how you think it could be made clearer. If your problem is simply that you don't understand the documentation, we suggest posting to the newsgroup comp.security.ssh and see if someone will explain what you need to know. Then, if you think the documentation could usefully have told you that, send us a bug report and explain how you think we should change it.
If you want to request a new feature in PuTTY, the very first things you should do are:
If you can't find your feature in either the development snapshots or the Wishlist, then you probably do need to submit a feature request. Since the PuTTY authors are very busy, it helps if you try to do some of the work for us:
If a feature is already listed on the Wishlist, then it usually means we would like to add it to PuTTY at some point. However, this may not be in the near future. If there's a feature on the Wishlist which you would like to see in the near future, there are several things you can do to try to increase its priority level:
If you're trying to make PuTTY do something for you and it isn't working, but you're not sure whether it's a bug or not, then please consider looking for help somewhere else. This is one of the most common types of mail the PuTTY team receives, and we simply don't have time to answer all the questions. Questions of this type include:
comp.security.ssh and see if someone can explain it to you.
comp.security.ssh and see if someone can solve your problem. Or try doing the same thing with a different SSH client and see if it works with that. Please do not report it as a PuTTY bug unless you are really sure it is a bug in PuTTY.
If you absolutely cannot get a support question answered any other way, you can try mailing it to us, but we can't guarantee to have time to answer it.
If the PuTTY web site is down (Connection Timed Out), please don't bother mailing us to tell us about it. Most of us read our e-mail on the same machines that host the web site, so if those machines are down then we will notice before we read our e-mail. So there's no point telling us our servers are down.
Of course, if the web site has some other error (Connection Refused, 404 Not Found, 403 Forbidden, or something else) then we might not have noticed and it might still be worth telling us about it.
If you want to report a problem with our web site, check that you're looking at our real web site and not a mirror. The real web site is at http://www.chiark.greenend.org.uk/~sgtatham/putty/; if that's not where you're reading this, then don't report the problem to us until you've checked that it's really a problem with the main site. If it's only a problem with the mirror, you should try to contact the administrator of that mirror site first, and only contact us if that doesn't solve the problem (in case we need to remove the mirror from our list).
PuTTY is distributed under the MIT Licence (see appendix C for details). This means you can do almost anything you like with our software, our source code, and our documentation. The only things you aren't allowed to do are to remove our copyright notices or the licence text itself, or to hold us legally responsible if something goes wrong.
So if you want permission to include PuTTY on a magazine cover disk, or as part of a collection of useful software on a CD or a web site, then permission is already granted. You don't have to mail us and ask. Just go ahead and do it. We don't mind.
(If you want to distribute PuTTY alongside your own application for use with that application, or if you want to distribute PuTTY within your own organisation, then we recommend you offer your own first-line technical support, to answer questions about the interaction of PuTTY with your environment. If your users mail us directly, we won't be able to tell them anything useful about your specific setup.)
If you want to use parts of the PuTTY source code in another program, then it might be worth mailing us to talk about technical details, but if all you want is to ask permission then you don't need to bother. You already have permission.
All mirrors of the PuTTY web site are welcome. Please don't bother asking us for permission before setting up a mirror. You already have permission. We are always happy to have more mirrors.
If you mail us after you have set up the mirror, and remember to let us know which country your mirror is in, then we'll add it to the Mirrors page on the PuTTY website.
If you have technical questions about the process of mirroring, then you might want to mail us before setting up the mirror; but if you just want to ask for permission, you don't need to. You already have permission.
One of the most rewarding things about maintaining free software is getting e-mails that just say ‘thanks’. We are always happy to receive e-mails of this type.
Regrettably we don't have time to answer them all in person. If you mail us a compliment and don't receive a reply, please don't think we've ignored you. We did receive it and we were happy about it; we just didn't have time to tell you so personally.
To everyone who's ever sent us praise and compliments, in the past and the future: you're welcome!
The actual address to mail is <putty@projects.tartarus.org>.