Client documentation

Contacts

- XXX PM Tel, email, skype
- XXX BA Tel, email, skype

Case reporting process

In order to help ensure an efficient and fast process for working through cases, please follow the following lines.

Client sets priority.

- High: urgent task, should be undertake first, stop the other tasks (normal & low) in progress
- Normal: undertake after 'High'
- Low: undertake after normal, when there is nothing else to do

Client to choose Type

- Bug: a behavior which is not working as expected
- Question: a question about a functionality
- Feature Request: a new case which was not in the initial specification
- General Task: other inquiries

Client provides a Title along following lines

You should be as precise and clear as possible when you give a summary (also called title) to the bug report.

- Bad title example: Problem in the forum
- Goog title: Error on replying to a thread, can't click on post button

Client provides a description (Body)

1. Provide the page that the issue is located on (copy paste the URL).
1. A step-by-step description on how to reproduce the issue (click here and here and do this and that etc...).
1. Provide your environment information (Windows XP/Vista, Firefox, Internet Explorer, Version 7...).
1. Note: _Ideally,_ only technical personnel add cases (in order to reduce time and energy required in clarification etc).
1. Client does not initially assigned the case, rather, {COMPANY} assigns the case to a developer.
1. The developer assigned to the case will comment and assigned back to client if he needs more info. When info are provided, client assign back to the developer.
1. At completion, the developer assigned to the case will reassign it to client with a comment "please review".
1. Client will test the result on UAT server.
1. Client will reassign back to the developer if there is still an issue, or, change status to "Resolved".

The wonderful story of bugs life (By Alex Gibson)

Once upon a time there was a bug. This bug was not a nasty, horrible bug, but rather just an annoying little creature that sometimes made things a little unpleasant. Of course there are nasty horrible bugs that make everything go horribly wrong, but most bugs are little and just a bit annoying. There are also other things that live amongst bugs. Things like questions, feature requests and general tasks. These other things are also important, but they are for another story. This story is about how a bug goes from a being little baby bug into a big, beautiful butterfly.

Bugs are little when they are new. They require an eye for detail. When a bug is found its usually hard to find again by someone else unless good instructions are given as to where it is. When someone finds a little bug, they need to make notes, take a photo, make a map and write a clear explanation for others to use. When this is done well, that little bug can be found more easily.

Once a bug is found, the information to find it again can be put into a case. This allows the budding bug catcher to use all their wits and skills to track it down. Bug catchers are a special breed. They know a lot about bugs. They are experts in finding them, working out how they live. They will find them put them in a jar and study them closely. They will look at their environment, how they interact with with other bugs. They will look at how they hurt and hinder their environment, but they will also look at what they are doing to make it work. Sometimes, just killing bugs is tempting, but this kind of reckless approach can only lead to other species of bugs breeding. This is why a careful approach is needed. This careful approach is what this story is about. It is about turning the bugs into beautiful butterflies, that everyone can admire.

A bug catcher needs clear information to find a bug. She will then need to find the bug and put it in a jar. Then the bug catcher can study the bug. Often the bug catcher will know what that bug is once they can look at it. They know a lot about bugs and they have seen many bugs before. Occasionally they will realise they are looking at a whole new species. This can be exciting for a bug catcher. They will go through a process of cataloging, testing and recording what they find in a case.

This is procedure when someone thinks they have found a new bug:

The person:

* Looks at their requirements and figures out if this is a bug or some other thing.
* Confirms that it is a bug and not a question, feature request or general task.
* Goes to the atrium and and confirms that this is not an existing bug with an existing case.
* Decides if the bug priority is high, normal or low. (note that if all bugs are high priority, then normal becomes meaningless)
* Writes a case for the bug describing how and where it was found.
* Once this is done, the bug catcher must be notified so that sh can do her job.

This is the procedure a bug catcher uses when someone finds a bug and creates a case.

The bug catcher:

* Uses the information in the case to find the bug for herself.
* They might know about the bug in which case they will fix the bug (and make its status 'resolved')
* They may not know about this particular bug and have to do some research.
* They may know about the bug, but it cannot be solved. This can be frustrating for everyone, but some problems just cannot be solved... we all know this, its like death or taxes. They just are.
* The bug catcher will notify the person who found the bug about what they now, or found out or did.
* Once a case is considered resolved, it is then up to the person who is responsible for the environment to decide if they are satisfied with the resolution, or if new information or decisions have been made to reopen the case.
* Once this procedure is done, the case can usually be closed. And when the case is closed the bug catcher can move on and work with other people and other bugs, as is there lot in life.

And when a case is closed the bug transforms magically into a big, beautiful butterfly. And this is the story of a bugs life.

Recommandation for production environment

* UNIX/Linux environment
- Windows is possible but we strongly recommend a UNIX/Linux environment

* Apache 2.x
- Modules: mod_rewrite extension to allow for clean URLs.
- Vhost example:

<VirtualHost *:80>
ServerName drupal.dev
ServerAlias www.drupal.dev
ErrorLog /home/web/drupal/logs/error_log
CustomLog /home/web/drupal/logs/access_log combined
DocumentRoot /drupal
<Directory /drupal>
        Options Indexes MultiViews SymLinksIfOwnerMatch
        AllowOverride All
        Order allow,deny
        Allow from all
</Directory>
</VirtualHost>

* Mysql 5.x
- Eventually binary logs activated for backup.
- Created user must be able to: SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES.

* PHP 5.2.x
- recommended php.ini: http://cvs.php.net/viewvc.cgi/php-src/php.ini-recommended?revision=1.179...

* Crontab
- Get http://server.dev/cron.php every 10 minutes
- Example:

[root@server ~]# crontab -l
*/10 * * * * wget -q http://server.dev/cron.php

* Migration
- We use subversion along the development with branches.
- The fastest and easy way to install and update the webite is to query our SVN server is to checkout our trunk (stable version) by SSH on port 61326 (we'll need you SSH public key). But we can also provide a tarball.
- To checkout:

user@vm:~$ cat .ssh/config
Host *XXX.com *XXX.org
   Port      61326
user@vm:~$ svn checkout svn+ssh://user@XXX.com/home/svn/XXX/trunk .

- SQL: we will include the lastest dump version with the files.