The user support offered by the kmeleon project is largely based on
users helping each other. Developers partake in helping users when
time permits.

There are manuals, tutorials and references written both by
developers and users. There are also open forums, like web-boards
and mailing lists, where you can get answers to your specific
questions by more experienced users. When you have solved your
problem, please consider to submit a tutorial, or a clarification
for the manual, that would have helped you solve your problem
quicker. That is to some extent how the current help pages have been
formed.

At the documentation page,
we offer a set of shorter tutorials that will help you get started with
some small, but commonly asked for, configuration tasks. There is
also a list of Frequently Asked Questions
(with answers). Once you are a bit more aqcuainted with K-Meleon you
should be able to digest the full manual. If you still cannot solve
the problem you are very welcome to turn to the K-Meleon forum.

Tip: The forum is archived and it can therefore pay off to search among
the old posts for questions similar to yours instead of posting the
same question once more. This will save time, both for you and others.

The K-Meleon web forum is the place where users and developers
meet to discuss problems in the current version as well as upcomming
features and feature requests for future versions.

Before you run off to ask questions at the web forum, grant us all
some respect by acting as an intelligent human being.

You will look pretty silly if the issue is already mentioned, and
solved, in the tutorials or FAQ. Always check there first.
After that, see if you can solve the problem yourself from reading
the manual. It is intended to include all information about the
browser. Not all answers, but all information. You will have to
apply the information on your problem to reach the answer.

When you decide that you cannot solve the problem yourself but have
to ask others for help, please remember that no one is obliged to
help you. Be polite. Take the time to reread what you have written
before you send it. Make sure it is clear what you want to achieve,
what you have tried, and what goes wrong. If you cannot make
yourself understood, or you come out as ignorant or demanding, you
are not likely to receive much attention.

A very good text about asking questions at open forums, where other
people will help you without any compensation, is the text How
to Ask Questions The Smart Way, by Eric S. Raymond.
Have you never thought of who will answer your questions and why,
this is great food for thoughts.

When you have become a more experienced user we would love to see
you as a trouble-solver, helping new users. If you go for the real
hard questions you might have to dig through the manual, use your
full creativity, and learn something in the process yourself. In
case you are not sure that you can give the correct answer you
should avoid guess working. Perhaps you at least know what expert
would be able to answer the question, and can help that way.

It would be most useful if you point out what information in the
manual could help the questioner find an answer himself. In the
beginning it is not easy to answer your own questions with the use
of a reference manual, but after a bit of practice everyone can do
it. "Teach a man to fish..."

If you think you have found something that might be a bug in
K-Meleon, please start by taking a big breath and calm down.
No one planted evil bugs in the program by will.

Remember that not everything that acts like a bug is a bug. And not
all bugs that affect K-Meleon are K-Meleon bugs. Sometimes it is a
user error, somtimes it is an error in another program, and
sometimes it really is a bug in K-Meleon. If you had any data losses
due to the problem it is as sad no matter what the reason is.
We understand your frustration and wish to help avoid that it ever
happens again. Often we need your help to diagnose the error.

When a site is not displaying properly it is normally caused by one
of two issues. Either the site is not compliant with current HTML
standards. It is the standards that tells how a browser should
interpret correctly written web pages. When a page violates the
standards there are no guarantess that all browsers will show it the
same. Let the web masters know such errors. If the page is fully
standards compliant the display problem is probably due to a bug, or
missing features, in Mozilla.

Before you start a big bug-hunting project try to find out if others
have spotted the same behaviour before you. Search the bug tracking
system and web board archives, or ask at one of the forums. If
others have experienced the same issue as you they will tell you the
current state of the problem. Sometimes this can be hints on how to
work around it while waiting for the real fix.

The key to understand what causes a malfunciton is being able to
reproduce the faulty behaviour. Faults that only happens once in a
blue moon are often extremely hard to fix. If your bug is mostly
harmless it would be very helpful if you could try to provoke it a
bit. Try to reproduced it. Write down the exact procedure to
trigger the bug if you find out how.

In case of application crashes you can use Dr.Watson to easily get
an idea of where the problem happened. Never bother with the
register dump from a blue screen, it is of no use at all. Search
Dr.Watson's log file for the latest appended entry, and make sure it
is K-Meleon. Write down what occurred. The comment on the exception
is important, not the number. Note the function that has an entry
marked with "FAULT". The function names in the Stack Back Trace for
the faulting thread are very important too. Unfortunately K-Meleon
is often stripped on debug information and symbol tables and thus
shows entries like 'nosymobls'.

With a bug you can reproduce, disable the plugins and see if the bug
persits or goes away. Disbale most other options from the preference
configure as well. Activate a few things at a time. Can you
localize the error? Is it a specific plugin that causes the errors?

Even if your bug is not fully reproducable but still happens now and
then try to find any common factors for the times it does happen.
What are you doing? How does the program respond? Try to observe as
much as possible that can help identify what goes wrong.

Writing a useful bug-report that leads to bugs being fixed is just
as hard, if not harder, than posing questions that others care to
answer. A good text to read before writing bug-reports is the text
How to
Report Bugs Effectively, by Simon Tatham. Take some of those
thoughts in consideration while writing your bug-report, and the bug
might actually get fixed quicker.

All bugs discovered and reported by users are kept in the bug
tracking system. Before you report something as a bug, make sure it
is truely a K-Meleon bug and that it is not already in the BTS. It
is a good idea to discuss the issue with others at the web-forum
first.

Note: Before you can enter your report you need to create an account with
the K-Meleon Bug Tracking System. To do this you must pick a name
and password as well as entering your e-mail address.

When you write your report you should make sure it is easy to see
already from the title what the bug is all about. Remeber to state
what version of K-Meleon, and any other programs involved, that you
use. Write the report in a way such that there are no doubts what
one can do to reproduce the bug, what goes wrong for you, and what
behaviour you expect to see instead. Write down any error messages
verbatim. Would you fail to express yourself clearly it is not
likely that anyone can understand what goes wrong for you. There are
too many bugs around to waste time on ghost hunts.

If you feel like being helpful, you could take a look at the BTS and
the current set of bugs. Several of the bugs are unconfirmed. Maybe
you are the detective to decipher what the bug-report talk about and
how one can reproduce the bug. Write a more clear comment in that
case. There are sometimes open bugs that actually have been fixed
already. Sometimes as a side effect from another bug fix or rewrite.
Write a comment on what tests you did to come to the conclusion that
the bug is no longer around.