Contractor information

General information about our IT process

Who are we, what are we doing ?

{COMPANY} is an IT company based in XXX concentrating on XXX software.
Please visit our website: http://{COMPANY}.com/.

Organization tools

Bugtracker

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

• Activity: what's happening on the projects, issues, last commits... It can be followed with RSS.
• Issues: all the tasks.
• Wiki: the requirements and documentation on the project.
• Repository: browsing Mercurial project files.
• Calendar: see when the tasks are scheduled.
• News: daily reporting on your work and any useful info about projects.

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

Skype

For each project, we create a Skype chatroom (see project wiki).

Contacts

• John Doe

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

Development

Best practices

• Never ever touch the software core (ex. do not modify the Drupal core files). For any features or modifications, you have to write a module. This allows easy further quick (security) updates.
• 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 the purpose of the module (can contain a 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 it and all useful information.
• If needed, update the project documentation page.
• Add comments to 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 it's possible.
• Supported modules or extensions in the software community should be used whenever 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 your development, be sure that it's working well and according to the original specifications.
• If the project requires, 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 for versionning.
Usual directory structure of a project:

	Trunk
	branches
		dev1
		dev1.1
		dev2
		...

- Trunk: contains the production files.
- Branches->devX: branch of developer
- Branches->devX.Y: branch of developer of another development, because the first development is maybe finished but not yet merged into the trunk.

Developer should commit as much as possible, if possible by adding comments. That way you prevent data loss and allow us to follow your work.
To put a development in production, after review, we merge the branch of the dev with the trunk.
Developer should never commit into trunk without an authorization.

Mercurial

We use Mercurial over SSH on port XXX.

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

Create ~/.hgrc and add:

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

Commands:
- hg clone ssh://user@dev.{COMPANY}.com//home/mercurial/{COMPANY}/
- 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 branch for each developer is created by project manger. Each developer works in his own branch.
• Tasks are assigned by project manager to the developers via bugtracker.
• Developers should do tasks by priority order unless instructed otherwise by project manager.
• Before undertaking the task, change the status to: 'In progress'.
• At task completion, write details about your work and how to push the development into production. It can contain some manual actions in the software administration (with screenshots), a SQL patch or a commit number. Then change the task status to 'Dev complete'.
• Project manager will test the code in your branch. During this, you can't undertake any other development. If you need to work on another development, a new branch will be created (ex. dev1.1).
• If it needs to go 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 change the status to 'Dev complete' again.
• Then project manager will merge the developer branch with the trunk and delete the branch of the developer (or create a new one from the trunk) and test the code on UAT.
• Project manager updates the status to 'OK production'.
• Project manager pushes the code to production and changes status to 'Resolved' - case is closed.

When a dev server is being set up, each branch may have its own access to our dev server. It should be devname.project.webXX.{COMPANY}.org

R&D

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

- http://testing.{COMPANY}.com/
- login/pass: XXX/XXX

Reporting

- Please report your hours on the case that you're assigned on, on a daily basis even if you don't complete the task.
- In addition, enter your time against your tasks. If asked by project manager, you may have to report your daily activities in the bugtracker news section.
- Please write a detailed comment when you solve an issue explaining how you solved it.

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 (p0{COMPANY}X).</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..).