History: developer_documentation

Source of version: 9 (current)

!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: john@do.com 
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. For consequent development and if asked please use [http://www.stack.nl/~dimitri/doxygen/|Doxygen].
* 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.
* Please use [fake_latin_text|fake latin text] for demo text as it allow everyone to know that it's demo text.
* Never write coarseness in the code and test data as it's easy to forget and so be visible by client.  

!!!!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 versioning.
Usual directory structure of a project:
<pre>
	Trunk
	branches
		dev1
		dev1.1
		dev2
		...
</pre>
- 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.
<pre>
user@vm:~$ cat .ssh/config
Host *{COMPANY}.com *{COMPANY}.org
   Port      XXX
</pre>

Create ~/.hgrc and add: 
<pre>
[ui]
username = John Do <john@example.com>
</pre>
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:
<pre>
syntax: glob
sites/default/settings.php
sites/default/files/*
*~
</pre>
!!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.

^For contractors^

!!Invoicing
Please read carefully this information as this allows us to pay you for the job that you've done.

For each issue, we will decide the type of invoicing method which can be either "Fixed quote" or "Hourly basis". 
For each case, the bugtracker 'Invoicing' field will tell you the invoicing type.  
 
!!!Fixed quote
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. 
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. 
If you do not succeed to deliver your commitment 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 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 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.

!!!Contract
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.

!!!Payment
* 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.
* For a payment based on a quote, please send us your invoice at job completion and we'll pay you within 30 days.
* 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>
* 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..).

SourceHistory

- A simple and Open process for web team management - Find Register Log in Username: Password: I forgot my password Register
	Sidebar Menu Home Search Categories Wiki Wiki Home Last Changes List Pages Orphan Pages Sandbox Multiple Print Structures Articles Articles Home List Articles Forums List Forums File Galleries List Galleries	History: developer_documentation View page Source of version: 9 (current) !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: john@do.com 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. For consequent development and if asked please use [http://www.stack.nl/~dimitri/doxygen/\|Doxygen]. * 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. * Please use [fake_latin_text\|fake latin text] for demo text as it allow everyone to know that it's demo text. * Never write coarseness in the code and test data as it's easy to forget and so be visible by client. !!!!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 versioning. Usual directory structure of a project: <pre> Trunk branches dev1 dev1.1 dev2 ... </pre> - 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. <pre> user@vm:~$ cat .ssh/config Host {COMPANY}.com {COMPANY}.org Port XXX </pre> Create ~/.hgrc and add: <pre> [ui] username = John Do <john@example.com> </pre> 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: <pre> syntax: glob sites/default/settings.php sites/default/files/* ~ </pre> !!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. ^For contractors^ !!Invoicing Please read carefully this information as this allows us to pay you for the job that you've done. For each issue, we will decide the type of invoicing method which can be either "Fixed quote" or "Hourly basis". For each case, the bugtracker 'Invoicing' field will tell you the invoicing type. !!!Fixed quote 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. 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. If you do not succeed to deliver your commitment 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 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 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. !!!Contract 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. !!!Payment * 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. * For a payment based on a quote, please send us your invoice at job completion and we'll pay you within 30 days. * 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> * 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..). SourceHistory
RSS: Wiki Articles File Galleries Forums This content is licensed under a Creative Commons Attribution 3.0 Unported License offered by Pierre Doleans and sponsored by Collabforge - Website powered by Tiki Wiki

Sidebar

Menu

History: developer_documentation

Source of version: 9 (current)