-\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
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
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
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
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
~mdw / sgt / putty / blobdiff