Contractor information

General information about our IT process

Who are we, what are we doing ?

XXX is an IT company based in XXX concentrate on XXX software.
Our clients are XXX. Please visit our website: <a href="http://XXX.com/">http://XXX.com/</a> and <a href="http://XXX.com/our-team">http://XXX.com/our-team</a>

Organization tools

Bugtracker

You're in! It contain all you need to know about the project, server access, contacts ...
We can create many accounts as you need.

• Activity: what happen on the projects, issues, last commit... It can be followed with RSS.
• Issues: you will find all the tasks from the projects, dev, features, bugs.
• Wiki: the requirement and documentation about the project.
• Repository: browsing Mercurial project files.
• Calendar: to see when the tasks are scheduled.
• News: to daily report your work and eventual useful info about the project.

Please write in Markdown in the text fields: http://help.couch.it/Markdown_Syntax

Skype

For each project, we create a skype chat (see project wiki).

Contacts

• John Doe

Role : IT project manager
Email:
Phone: +000000000
Skype: johnyskype

Development

Best practices

• Never ever touch to the software core (ex. do not modify the Drupal core files). For any feature or modifications, you have to write a module. That allow easy further quick (security) update.
• Document your code. For example if you built a Drupal module, put a README.txt in the same directory as your module. It should contain, What this module is use for (can contain the link to the bugtracker task) how to install it, how to use it and which changes are needed in the software admin, how to test it, how to access to it and all useful information.
• If needed, update the project documentation page.
• Comment your code when you're doing something unusual.
• Follow the best practices of the software recommendation (put the module in the right place, use the right and standard procedure development...).
• CSS should be used whenever possible.
• Supported modules or extensions in the software community should be used whenever is possible instead of undertaking the same development.
• If you're going to use a module for a feature, check the license, it must be a GPL like license.
• Test, test and test again, when you're going to deliver a development, be sure that it's working well and according to the original specifications.
• If project required, you may have to build non regression unit tests.

Community work

Contributions to the open source community when you develop or fix something are recommended and encouraged. When you submit something please put the author as "your name - COMPANY.com"

Versioning

We use Mercurial and SVN for old projects.
Usual directory structure of a project:

	Trunk  
	branches
		dev1
		dev1.1
		dev2
		...

- Trunk: contain the production files.
- Branches->devX: branche of developer
- Branches->devX.Y: branche of developer of another development, because the first development is maybe finish but not yet merge into the trunk.

Developer should commit as most as possible, if possible with comments (and always in trunk). That way you prevent data losing and allow us to follow developer work.
To put a work in production, after review, we merge the branche of the dev with the trunk.
Except our agreement, developer should never commit into trunk.

SVN

For windows look here: <a href="http://tortoisesvn.net/ssh_howto">http://tortoisesvn.net/ssh_howto</a>
We use SVN over SSH on port XXX.

user@vm:~$ cat .ssh/config
Host *XXX.com *XXX.org
   Port      XXX

Mercurial

Create ~/.hgrc and add:

[ui]
username = John Do <john@example.com>

Commands:
- hg clone ssh://user@dev.XXX.com//home/mercurial/XXX/
- hg update
- hg commit
- hg pull
- hg push

Ignore:
Create a .hgignore file at the ROOT directory of the project.
- Example:

syntax: glob
sites/default/settings.php
sites/default/files/*
*~

QA process

• A branche for each developer is created by project manger. Each developer work in his own branch.
• Tasks are assigned by project manager to the developer via bugtracker.
• Developer should do the tasks by priority order when they have no different instructions from project manager.
• Before undertaking the task, change the status to: 'In progress'.
• At task completion, you write details about your work and how to push the development in production. It can contain some manual human actions to do in the software administration (with screenshot), a SQL patch or a commit number. Then you put the task in status 'Dev complete'.
• Project manager test the code in your branche. During this, you can't undertake any other development. If you need to work on another development, a new branche will be created (ex. dev1.1).
• If it need back and forth between project manager and you, project manager will change the status to 'In progress' and add a comment describing the problem. You will fix it and put the case to 'Dev complete' again.
• Then project manager merge the developer branche with the trunk and delete the branche of the developer (or create a new one from the trunk) and test the code on UAT.
• Project manager update the status to 'OK production'.
• Project manager push the code in production and change status to 'Resolved', case is closed.

When a dev server in setting up, each branche may have it own access on our dev server. It should be devname.project.webXX.XXX.org

R&D

You can test and play with some software that we're using here:

- http://testing.XXX.com/
- login/pass: XXX/XXX

Reporting

- Please report your time daily on the case your are assign on even if you don't complete the task.
- In addition to enter your time against your tasks, If asked by project manager, you may have to report your daily activities in the bugtracker news section.
- When you solve an issue, please put in the issue a detailed comment which explained how you solved the issue.

Invoicing

Please read carefully this information as they allow us to pay you for the job you've done.

For each issues, we will decide the type of invoicing method which can be "Fixed quote" or "Hourly basis".
For each case, the bugtracker field 'Invoicing' will tell you the invoicing method type.

Fixed quote

Each time is possible, we prefer you to give us a quote according the job description. Then you will engage yourself to succeed to your task in the defined time to spent and due date.
The time to spent (and so amount) will be entered in the 'Estimated hours' filed of each bugtracker issues. The deadline will be entered in the 'Due Date' field of each bugtracker issues.
If you do not succeed to deliver the promise at the due date, penalties will apply on the defined amount at the following rates:

• 10% if over 1 week,
• 20% if over 2 weeks,
• 30% if over 3 weeks.

Answer to a quote

You can quote the tasks with the status 'Quote' unassigned, or assigned to you.
Read the description and send an email to PM with the price in USD including your deadline, do not answer to the quote with a task comment.
We need your quote before the 'Due date'.

Hourly base

When it's too difficult to work with a fixed quote, we will work on hourly basis. In this case a maximum spent time and a deadline will be fixed. Estimated time will be put in the 'Estimated time' field of bugtracker. If you do not succeed to solve the issue in the given time, then put a comment in the issue explaining how you used the time, your actual position and estimate how long it will take you to solve the issue. Then project manager will answer to you.

Contract

Please read and sign our contract (attached in the end of this page, SoleTraderContractorAgreement.odt) and send it to project manager.

Payment

• For a hourly payment, please send us a monthly invoice with your time. We will check time against bugtracker and we'll pay you by 30 days.
• For a payment based on a quote, please send us your invoice at job completion and we'll pay you by 30 days.
• Your invoice must be broken down in hours and by projects and sub project you have been worked on including project number (p0XXXX).</b>
• Please include the currency in your invoice, your payment details, name, address and invoice number.
• Our preferred payment method is a wire transfer, please provide your banking details (bank name, city, address linked to the bank account, bank account number, routing details etc..).