X-Git-Url: https://git.distorted.org.uk/~mdw/sgt/putty/blobdiff_plain/3c42d11863f51a4ab66752e90bf6a11013580875..8a6c27512ee11e8102da6dd773250b096d079c1a:/doc/feedback.but diff --git a/doc/feedback.but b/doc/feedback.but index d1ef1e3d..53872a5c 100644 --- a/doc/feedback.but +++ b/doc/feedback.but @@ -1,9 +1,10 @@ -\versionid $Id: feedback.but,v 1.1 2001/12/16 14:56:02 simon Exp $ +\versionid $Id: feedback.but,v 1.7 2002/08/07 18:08:29 simon Exp $ \A{feedback} Feedback and bug reporting -This section describes what to do if you want to contact the PuTTY -development team. +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. \K{feedback-general} gives some general guidelines for sending any kind of e-mail to the development team. Following sections give more @@ -18,43 +19,71 @@ FAQ, reading the web site, asking a fellow user, perhaps posting on the newsgroup \W{news:comp.security.ssh}\c{comp.security.ssh}, or some other means, then it would make our lives much easier. -If the volume of e-mail really gets on top of us and we can't find -time to answer it all, then the first e-mails we discard will be the -ones from people who don't look as if they have made a reasonable -effort to solve their own problems. This is not intended to cause -offence; it's occasionally a necessary response to a serious -problem. We get a \e{lot} of e-mail. Really. - -Also, the PuTTY contact email address is a mailing list. For this -reason, 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. Therefore: - -\b Don't send your bug report 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 attachment to a Windows box to run Word is -very inconvenient. Not only that, but several of us don't even -\e{have} a copy of Word! - -\b Don't mail large screen shots without checking with us first. +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 \e{possibly} avoid sending mail to the PuTTY team, we +recommend you do so. In particular, support requests +(\k{feedback-support}) are probably better sent to +\W{news:comp.security.ssh}\c{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. + +\S{feedback-largefiles} Sending large attachments + +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 \e{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 \e{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. Sending a full-screen shot is sometimes useful, but it's -probably still wise to check with us before sending it. +was. Sending a full-screen shot is \e{occasionally} useful, but it's +probably still wise to check whether we need it before sending it. -\b If you want to send us a screen shot, or any other kind of large -data file, it is much more convenient for us if you can put the file -on a web site and send us the URL. That way (a) we don't have to -download it at all if it doesn't look necessary; and (b) only one -member of the team needs to download it, instead of it being -automatically sent to everyone on the mailing list. - -\b If you \e{must} mail a screen shot, don't send it as a \cw{.BMP} +If you \e{must} mail a screen shot, don't send it as a \cw{.BMP} file. \cw{BMP}s have no compression and they are \e{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. For security reasons, it +would be really unwise of us to run executables we receive from +unknown people by e-mail, so there's no point sending them to us. At +some point, indeed, we hope to block all incoming e-mail containing +executables, as a defence against the vast numbers of e-mail viruses +we receive every day. + +If you have made a tiny modification to the PuTTY code, please send +us a \e{patch} to the source code if possible, rather than sending +us a huge \cw{.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. + \H{feedback-bugs} Reporting bugs If you think you have found a bug in PuTTY, your first steps should @@ -139,6 +168,17 @@ is an article on how to report bugs effectively in general. If your bug report is \e{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 \e{what} you think the documentation has +failed to tell you, or \e{how} you think it could be made clearer. +If your problem is simply that you don't \e{understand} the +documentation, we suggest posting to the newsgroup +\W{news:comp.security.ssh}\c{comp.security.ssh} and see if someone +will explain what you need to know. \e{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. + \H{feedback-features} Requesting extra features If you want to request a new feature in PuTTY, the very first things @@ -213,6 +253,41 @@ high-quality software to the users comes first.) way to get a feature implemented quickly, if it's a big one that we don't have time to do ourselves. +\H{feedback-support} Support requests + +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 +\e{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: + +\b If you want to do something with PuTTY but have no idea where to +start, and reading the manual hasn't helped, try posting to the +newsgroup \W{news:comp.security.ssh}\c{comp.security.ssh} and see if +someone can explain it to you. + +\b If you have tried to do something with PuTTY but it hasn't +worked, and you aren't sure whether it's a bug in PuTTY or a bug in +your SSH server or simply that you're not doing it right, then try +posting to \W{news:comp.security.ssh}\c{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 \e{is} a bug +in PuTTY. + +\b If you have successfully made a connection to your server and now +need to know what to type at the server's command prompt, or other +details of how to use the server-end software, talk to your server's +system administrator. This is not the PuTTY team's problem. PuTTY is +only a communications tool, like a telephone; if you can't speak the +same language as the person at the other end of the phone, it isn't +the telephone company's job to teach it to you. + +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. + \H{feedback-webadmin} Web server administration If the PuTTY web site is down (Connection Timed Out), please don't @@ -225,6 +300,17 @@ Of course, if the web site has some other error (Connection Refused, 404 Not Found, 403 Forbidden, or something else) then we might \e{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 \e{real} web site and not a mirror. The real web site +is at +\W{http://www.chiark.greenend.org.uk/~sgtatham/putty/}\c{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). + \H{feedback-permission} Asking permission for things PuTTY is distributed under the MIT Licence (see \k{licence} for