The development team recommends that you use the product's forums to search for the problem encountered, and then start a new forum discussion, before opening a bug report.
Creating a (free) SourceForge user account, and using it for posting on forums, is highly recommended. This enables better tracking of questions and answers.
It's important to choose the summary title carefully when you start a new forum thread. Titles such as "Help me!", "Help a newbie!", "Problem", or "phpMyAdmin error!" are difficult to deal with, as the answers are threaded to these titles and further reference becomes problematic. Better titles would be: "Import with UploadDir", "User can't but root can login", or "Server not responding".
As people will read and, almost always answer, your question(s), giving feedback in the forum about the answers can really help the person who answered, and also help others also help who encounter the same problem.
The support tracker is another place to ask for support. Also, if we have submitted a bug report, which is in fact a support request, the report will be moved to the support tracker. If you have a SourceForge user account, you will be notified of this tracker change.
In this tracker, we see bugs that have not yet been fixed, along with the bugs that have been fixed for the next version. (This is to avoid getting duplicate bug reports.)
As developers will try to reproduce the problem mentioned, it helps to describe your environment. This description can be short, but should contain the following items:
phpMyAdmin version (the team, however, expects that it's the current stable version)
Web server name and version
PHP version
MySQL version
Browser name and version
Usually, it isn't necessary to specify the operating system on which the server or the client is running, unless we notice that the bug pertains to only one OS. For example, FAQ 5.1 describes a problem where the user could not create a table having more than fourteen fields. This happens only in Windows 98.
We should give a precise description of what happens (including any error message, the expected results, and the effective results we get). Reports are easily managed if they describe only one problem per bug report (unless the problems are clearly linked).
Sometimes, it might help to attach a short export file to the bug report, to help developers to reproduce the problem. Screenshots are also welcome.