Paid Support Guidelines

Paid Support Website Module

The paid support module provides a way for developers to track the paid support tickets. It's split into three parts: unassigned tickets (no developer has taken control of the ticket yet), pending (the ticket is in the pending or in-progress status) and closed (the ticket is completed or abandoned). You can also add annotations to the tickets, which should be used to tell other developers (or yourself) any information about the ticket you think appropriate -- it is not imperitive to use annotations for each ticket, but it's a useful organization tool.

Ticket statuses

• Open - i.e. unassigned. No developer has taken this ticket yet. You're welcome to take a ticket if it's in the "Open" status
• Pending - This is what you should set the ticket to notify other developers you are going to contact the user. You should set this before you contact the user to prevent multiple emails being sent
• In-Progress - When you've discussed the ticket with the user and are now ready to start on the ticket, set this status
• Closed - When the ticket has been successfully completed
• Abandoned - For some reason, the ticket was not completed. This could be because the user backed out, an incompatible host, no response, etc.. It's probably a good idea to add an annotation to the ticket if you abandon it.
• Invalid - For some reason, the ticket was invalid. Examples include: not willing to pay, difficult customization nobody wants to take, etc...

Contacting the user

When you've picked a ticket you want to do and set the status to "Pending", the next step is to contact the user. You should be sure to include the "confirmation code" listed on the ticket website module. Also, you should rehash in short the things said on the ticket submission page so that the user knows exactly what they're doing and they've followed all the requirements. You should make sure the user is aware of the price of the option they picked and how to pay you (i.e. PayPal). Finally, you should ask the user for any specific requirements (for a regular install, things like "gallery title", any features they wanted enabled, and other config wizard variables; for a customization, make sure to get the specific requirements of what they want).

What to do when you are logged in

You want to be extremely careful when you are working on a user's host. Here are some dos/don'ts from Beckett

1. If someone gives you root access, be sensible. Alias "rm -i" immediately (or "touch -i" in the directory you're in) to prevent silly mistakes, regardless of how quick you expect things to be.
2. Don't assume that the webserver can be stopped and restarted. Never undertake things like modifying apache/php config files without *express* consent from the person first (that means explaining what you want to do and why). I cannot overemphasize how important it is that there be *no* mistakes made where things break or get deleted by accident. Don't assume "oh if I just do *blank* it'll all be done". Put yourself in that person's position. If you'd rather you were asked before someone did *blank* on your server, then you need to send another email and wait for the reply. Even if you're 99.9% sure it's okay
3. Along these lines, if you're upgrading a Gallery version, be 100% sure to back up the old gallery/album directories first. No exceptions. If there's no space to back up the albums, use Joan's backup script to suck the critical data to your server locally. I usually leave the backed up data for the person and say "if everything is fine after a few days, go ahead and delete the backup stuff".
4. When you reply to emails, don't include the password info sent to you in the first email. We want to reduce the overall amount of passwords flying around the net in plaintext. Also, when you're done, remind your user to change the password to something new, and get rid of your own record of the info.
5. Don't compile anything (NetPBM, Jhead) on Linux with GCC 2.96 or 3.0... they have big bugs, but are what shipped with RedHat 7, so very common.
6. What to say when the person says, "oh yeah, can you also add e-cards and the random block?" Just tell him/her that that's more work and that either you'll do it for X dollars, or to resubmit a new request for someone else to pick up.
7. Don't let yourself become that person's "web admin bitch". Explain that you're here to make sure Gallery gets installed (or whatever), but that you can't be depended upon to be there in the future. This usually sets the record straight. It's good practice to send an email when you're done explaining in some detail what you did.
8. Explain how to get back into Config. Mode, and how to edit background colours, etc. I have a boilerplate email I use for this... It will cut down on the "oh just one more quick thing" type emails, plus it scores you brownie points, and you might even get a marriage proposal (don't ask... though I've been there).
9. Don't forget to test your install. That means uploading a test photo (via HTTP to make sure file_uploads is on) and rotating at the very least. If zip support is added, make sure to test a zip too.

Other tips

Here are some random tips from experience