When providing support in your capacity as a Virtualmin support rep, the following guidelines should be followed:

Do

Check the docs first, and do a site search. If you can link someone to relevant documentation and/or previous discussions in your reply, it will be more helpful to the user and your answer can be shorter and quicker. If there are no docs, and you think there should be, or the docs aren't good or complete, file a ticket assigned to Joe and Eric about the thread and mention that it should be a documented aspect of the product. If we really like your answer, we will merge it into the docs. If I think it needs some work, I'll tweak it a bit and then merge it, also possibly correcting any misinformation in the thread. There are over ten thousand comments on the website, and over 1000 printed pages of documentation. A lot of questions have been asked, and possibly answered, before. Just be careful not to suggest outdated information...so you do need to read a bit of the thread or docs you're linking to. If they are out of date, don't link them. If there are docs that are out of date, file a ticket for Joe and Eric and, optionally, update them to reflect more recent reality.

Be friendly and fast. If it's in the ticket tracker, take ownership the moment you see an issue you can answer, and answer as soon as possible; if you aren't going to address the question immediately, leave it unassigned or assign to someone else. In forums, just say you'll bring it to the attention of someone else, or leave it for others. In support tickets, assign the ticket to the person you think best able to field the question. The following are some rough guidelines for who to assign tasks to:

Jamie is responsible for bugs and bug-like issues in everything except the install process. If the user has reported a Perl error anywhere in Webmin or Virtualmin, it is almost certainly a ticket for Jamie. If it is an Install Script version upgrade request, it is also for Jamie. Jamie knows how to answer nearly every question...but his time is the least available for support, so he should be reserved for the really hard stuff and bugs (but bugs should always go right to Jamie, because it would just be a waste of someone elses time to re-assign it yet again). To repeat: Jamie is the last resort, except for bugs and install script version updates.

Joe is responsible for installation related issues (anything in the yum/apt-get repositories, and occurring during the virtualmin-install.sh run). Joe is also responsible for website, licensing, reseller/partner program, and download issues. Non-technical issues, like billing, bad links, refund requests, also go to Joe.

Eric is a good compromise if you don't know who to assign the ticket to, as he knows at least as much as Joe and probably not much less than Jamie. If he doesn't have an answer, he will probably know whether Jamie or Joe is the best choice. When in doubt, Eric is your man.

If the user has not identified their OS and version, ask. It almost always matters in the solution. Likewise Virtualmin GPL vs. Professional (we're working on making it impossible to file a support issue without a valid license...but that's not currently working yet). And forum posts will always be up in the air...it could be GPL or Professional. So, if it's related to a feature that is different across versions, we'll either need to know or provide both answers.

If things look really weird, ask how they installed Virtualmin. 90% of the time, they installed manually, and have skipped a dozen or two steps in the process of configuring and setting up their system. Recommend virtualmin-install.sh, if it is possible (i.e. they have a supported OS and it is not yet in production).

Don't

Never recommend third party package sources as a solution to a problem. If the user requires a package that is not provided by their OS, or by our repositories (including bleeding edge), check to see if it is available in EPEL (for Alma/Rocky/CentOS/RHEL) or volatile (for Debian) or universe (for Ubuntu). Third party package sources are known to cause significant trouble for non-technical users, and increases the support burden dramatically down the road. If we recommend them and things go wrong (as they almost certainly will) we will catch the blame. We catch the blame on a daily basis for third party packages, anyway, despite our best efforts to discourage careless usage of such packages.

Never recommend building packages from source or installing from CPAN or Ruby gems, what can be installed from yum of apt-get. If the package is available in the OS repositories, that is where it should come from.

Never recommend bleeding edge versions (from our bleeding edge repository) if the OS-standard packages will work just as well. Do recommend bleeding edge packages from our repo when users have versions from third party sources that are causing them problems.

Be friendly, and be as helpful as possible, but try to avoid logging into the users system, whenever possible. It is time-intensive, and opens up additional areas for reputation problems. Again, the more hands on we get, the more likely we are to catch blame for things we have no control over. Give a man a fish and he'll eat for a day, teach a man to fish and he'll manage his own servers for the rest of his life. Or something. That said, sometimes logging in is the fastest way to a solution. Recommend the Support module for enabling remote logins by us when logging in will resolve the problem most quickly. Logging in is only an option for paying customers. (If Joe hasn't updated this to tell you how to find out if the user is a paying customer, then it probably isn't supported yet. But I'm working on it.)

Never recommend a manual install of Virtualmin. If the user cannot install using the install script, consider asking them why, or if they could install a fresh system to install on. Manual installs are challenging, even for experts, and extremely time-consuming. Not to mention people who install Virtualmin manually will ask at least 10 times as many questions and run into dramatically more "angry" situations. User satisfaction is dramatically lower with manually installed systems, because it is so hard to get it right.