Jump to Content
History: developer_documentation

Source of version: 7

Version
!Contractor information<br />
<br />
!!General information about our IT process<br />
<br />
!!!Who are we, what are we doing ? <br />
{COMPANY} is an IT company based in XXX concentrating on XXX software. <br />
Please visit our website: http://{COMPANY}.com/.<br />
<br />
!!!Organization tools<br />
<br />
!!!!Bugtracker<br />
You're in it! It contains all you need to know about the projects, server access, contacts ...<br />
We can create as many accounts as you need.<br />
* Activity: what's happening on the projects, issues, last commits... It can be followed with RSS.<br />
* Issues: all the tasks.<br />
* Wiki: the requirements and documentation on the project. <br />
* Repository: browsing Mercurial project files.<br />
* Calendar: see when the tasks are scheduled.<br />
* News: daily reporting on your work and any useful info about projects.<br />
Please write in Markdown in the text fields: http://help.couch.it/Markdown_Syntax<br />
<br />
!!!!Skype<br />
For each project, we create a Skype chatroom (see project wiki).<br />
<br />
!!!!Contacts<br />
*John Doe <br />
Role : IT project manager<br />
Email: john@do.com <br />
Phone: +000000000 <br />
Skype: johnyskype<br />
<br />
!!!Development<br />
<br />
!!!!Best practices<br />
* 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.<br />
* 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. For consequent development and if asked please use [http://www.stack.nl/~dimitri/doxygen/|Doxygen].<br />
* If needed, update the project documentation page.<br />
* Add comments to your code when you're doing something unusual.<br />
* Follow the best practices of the software recommendation (put the module in the right place, use the right and standard procedure development...).<br />
* CSS should be used whenever it's possible.<br />
* Supported modules or extensions in the software community should be used whenever possible instead of undertaking the same development.<br />
* If you're going to use a module for a feature, check the license, it must be a GPL like license.<br />
* 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.<br />
* If the project requires, you may have to build non regression unit tests.<br />
<br />
!!!!Community work<br />
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"<br />
<br />
!!!!Versioning<br />
<br />
We use Mercurial for versioning.<br />
Usual directory structure of a project:<br />
<pre><br />
	Trunk<br />
	branches<br />
		dev1<br />
		dev1.1<br />
		dev2<br />
		...<br />
</pre><br />
- Trunk:	        contains the production files.<br />
- Branches->devX:	branch of developer<br />
- Branches->devX.Y:	branch of developer of another development, because the first development is maybe finished but not yet merged into the trunk.<br />
<br />
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.<br />
To put a development in production, after review, we merge the branch of the dev with the trunk.<br />
Developer should never commit into trunk without an authorization.<br />
<br />
!!!!!Mercurial<br />
We use Mercurial over SSH on port XXX.<br />
<pre><br />
user@vm:~$ cat .ssh/config<br />
Host *{COMPANY}.com *{COMPANY}.org<br />
   Port      XXX<br />
</pre><br />
<br />
Create ~/.hgrc and add: <br />
<pre><br />
[ui]<br />
username = John Do <john@example.com><br />
</pre><br />
Commands:<br />
- hg clone ssh://user@dev.{COMPANY}.com//home/mercurial/{COMPANY}/<br />
- hg update <br />
- hg commit <br />
- hg pull <br />
- hg push<br />
<br />
Ignore:<br />
Create a .hgignore file at the ROOT directory of the project.<br />
- Example:<br />
<pre><br />
syntax: glob<br />
sites/default/settings.php<br />
sites/default/files/*<br />
*~<br />
</pre><br />
!!QA_process<br />
* A branch for each developer is created by project manger. Each developer works in his own branch.<br />
* Tasks are assigned by project manager to the developers via bugtracker.<br />
* Developers should do tasks by priority order unless instructed otherwise by project manager.<br />
* Before undertaking the task, change the status to: 'In progress'. <br />
* 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'.<br />
* 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).<br />
* 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.<br />
* 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.<br />
* Project manager updates the status to 'OK production'.<br />
* Project manager pushes the code to production and changes status to 'Resolved' - case is closed.<br />
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 <br />
<br />
!!R&D <br />
You can test and play with some software that we're using here:<br />
 <br />
- http://testing.{COMPANY}.com/<br />
- login/pass: XXX/XXX<br />
<br />
!!Reporting<br />
- Please report your hours on the case that you're assigned on, on a daily basis even if you don't complete the task.<br />
- 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.<br />
- Please write a detailed comment when you solve an issue explaining how you solved it.<br />
<br />
^For contractors^<br />
<br />
!!Invoicing<br />
Please read carefully this information as this allows us to pay you for the job that you've done.<br />
<br />
For each issue, we will decide the type of invoicing method which can be either "Fixed quote" or "Hourly basis". <br />
For each case, the bugtracker 'Invoicing' field will tell you the invoicing type.  <br />
 <br />
!!!Fixed quote<br />
Each time it's possible, we prefer you to give us a quote according to the job description. Then you will engage yourself to succeed in your task in the defined time frame and due date. <br />
The time to be spent (and so budget) will be entered in the 'Estimated hours' field of each bugtracker issue. The deadline will be entered in the 'Due Date' field of each bugtracker issue. <br />
If you do not succeed to deliver your commitment at the due date, penalties will apply on the defined amount at the following rates: <br />
* 10% if over 1 week, <br />
* 20% if over 2 weeks, <br />
* 30% if over 3 weeks.<br />
<br />
!!!!Answer to a quote<br />
You can quote the tasks with the status 'Quote' unassigned, or assigned to you. <br />
Read the description and send an email to PM with the price in USD including your deadline, do not answer the quote with a task comment.<br />
We need your quote before the 'Due date'.<br />
<br />
!!!Hourly base <br />
When it's too difficult to work with a fixed quote, we will work on hourly basis. In this case, a maximum time spent and a deadline will be fixed. Estimated time will be in the 'Estimated time' field of bugtracker. If you do not succeed to solve the issue in the given time, then write a comment on the issue explaining how you used the time, your actual status and estimate how long it will take you to solve the issue. Then project manager will reply.<br />
<br />
!!!Contract<br />
Please read and sign our contract (attached in the end of this page, {FILE(fileId=16)}SoleTraderContractorAgreement.odt{FILE}) and send it to the project manager.<br />
<br />
!!!Payment<br />
* For hourly basis payment, please send us a monthly invoice with your working hours. We will check that time against bugtracker and we'll pay you within 30 days.<br />
* For a payment based on a quote, please send us your invoice at job completion and we'll pay you within 30 days.<br />
* Your invoiced working hours must be broken down by projects and sub projects that you have been working and including the project number (p0XXXX).</b><br />
* Please include the currency in your invoice, your payment details, name, address and invoice number.<br />
* 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..).
History

Advanced
Legend: v=view , s=source
Date	User	Version	Action
Thu 12 of Aug., 2010 20:10 UCT	System Administrator	9 Current	v s
Wed 11 of Aug., 2010 16:50 UCT	System Administrator	8	v s
Wed 11 of Aug., 2010 16:28 UCT	System Administrator	7	v s
Wed 11 of Aug., 2010 16:24 UCT	System Administrator	6	v s
Wed 11 of Aug., 2010 01:57 UCT	System Administrator	5	v s
Tue 10 of Aug., 2010 13:16 UCT	System Administrator	4	v s
Tue 10 of Aug., 2010 04:54 UCT	System Administrator	3	v s
Mon 09 of Aug., 2010 22:17 UCT	System Administrator	2	v s
Mon 09 of Aug., 2010 15:30 UCT	System Administrator	1	v s
Enable pagination per page
SourceHistory
Sidebar

Menu

History: developer_documentation

Source of version: 7

History
