feedback.but

putty

you should do are:

\b Check the
\W{http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/}{Wishlist
page} on the PuTTY website, and see if your feature is already on
the list. If it is, it probably won't achieve very much to repeat
the request. (But see \k{feedback-feature-priority} if you want to
persuade us to give your particular feature higher priority.)

\b Check the Wishlist and
\W{http://www.chiark.greenend.org.uk/~sgtatham/putty/changes.html}{Change
Log} on the PuTTY website, and see if we have already added your
feature in the development snapshots. If it isn't clear, download
the latest development snapshot and see if the feature is present.
If it is, then it will also be in the next release and there is no
need to mail us at all.

If you can't find your feature in either the development snapshots
\e{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:

\b Do as much of the design as you can. Think about \q{corner
cases}; think about how your feature interacts with other existing
features. Think about the user interface; if you can't come up with
a simple and intuitive interface to your feature, you shouldn't be
surprised if we can't either. Always imagine whether it's possible
for there to be more than one, or less than one, of something you'd
assumed there would be one of. (For example, if you were to want
PuTTY to put an icon in the System tray rather than the Taskbar, you
should think about what happens if there's more than one PuTTY
active; how would the user tell which was which?)

\b If you can program, it may be worth offering to write the feature
yourself and send us a patch. However, it is likely to be helpful
if you confer with us first; there may be design issues you haven't
thought of, or we may be about to make big changes to the code which
your patch would clash with, or something. If you check with the
maintainers first, there is a better chance of your code actually
being usable. Also, read the design principles listed in \k{udp}: if
you do not conform to them, we will probably not be able to accept
your patch.

\H{feedback-feature-priority} Requesting features that have already
been requested

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 \e{near} future, there are
several things you can do to try to increase its priority level:

\b Mail us and vote for it. (Be sure to mention that you've seen it
on the Wishlist, or we might think you haven't even \e{read} the
Wishlist). This probably won't have very \e{much} effect; if a huge
number of people vote for something then it may make a difference,
but one or two extra votes for a particular feature are unlikely to
change our priority list immediately. Offering a new and compelling
justification might help. Also, don't expect a reply.

\b Offer us money if we do the work sooner rather than later. This
sometimes works, but not always. The PuTTY team all have full-time
jobs and we're doing all of this work in our free time; we may
sometimes be willing to give up some more of our free time in
exchange for some money, but if you try to bribe us for a \e{big}
feature it's entirely possible that we simply won't have the time to
spare - whether you pay us or not. (Also, we don't accept bribes to
add \e{bad} features to the Wishlist, because our desire to provide
high-quality software to the users comes first.)

\b Offer to help us write the code. This is probably the \e{only}
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} \ii{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 a
newsgroup (see \k{feedback-other-fora}) 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 a newsgroup (see \k{feedback-other-fora}) 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 someone else installed PuTTY for you, or you're using PuTTY on
someone else's computer, try asking them for help first.  They're more
likely to understand how they installed it and what they expected you
to use it for than we are.

\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 \i{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 \e{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
\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
details). This means you can do almost \e{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 \e{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, but do not insist, that
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.

If you just want to link to our web site, just go ahead. (It's not
clear that we \e{could} stop you doing this, even if we wanted to!)

\H{feedback-mirrors} Mirroring the PuTTY web site

\#{This paragraph also in putty-website/mirrors.html}
Mirrors of the PuTTY web site are welcome, especially in regions not
well covered by existing mirrors. (However, if you're in a region that is
already well served by mirrors, you should consider whether yet another one
will be worth the effort.) Please don't bother asking us for permission before
setting up a mirror. You already have permission.

If you mail us \e{after} you have set up the mirror and checked that
it works, and remember to let us know which country your mirror is in,
then we'll add it to the
\W{http://www.chiark.greenend.org.uk/~sgtatham/putty/mirrors.html}{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 (see also the
\W{http://www.chiark.greenend.org.uk/~sgtatham/putty/mirrors.html#guidelines}{guidelines on the Mirrors page});
but if you just want to ask for permission, you don't need to. You
already have permission.

\H{feedback-compliments} Praise and compliments

One of the most rewarding things about maintaining free software is
getting e-mails that just say \q{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, \e{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: \e{you're welcome}!

\H{feedback-address} E-mail address

The actual address to mail is
\cw{<\W{mailto:[e-mail]}{[e-mail]}>}.