Contribution guidelines

Keep in mind that dibber is in early stage of development wich makes it an application subject to a lot of changes until it reaches a more mature state.

Specifications, main ideas

The specifications of the application are not totally designed yet. As this subject requires a lot of back and forth discussions, it takes place in this mailing-list. We're not trying to make a full scope statement though, but we're rather looking into making things easy to understand by (when possible) visualy designing what we want to see in the application.

As an example there are already 2 in progress mockups of different designs :

• version 1 with clickable links - hold shift to see them
• version 2 without links yet - use the arrows to get thru the pages

Another way to express in an easy to understand way what could be in the application is by writing little stories about that specific thing. It would describe it in the context of being used by someone. Some generic stories about the whole application are on their way and should be available soon.

Development

The application is made using these main technologies :

• Zend Framework 2
• MongoDB for data persistence
• Doctrine 2 ODM
• PHP 5.4
• Client-side is still open to discussion but i(jhuet) think that Backbone + ModelBinder is a good combinaison

Installation

The easiest way to do so is by using both git and composer. If you have none you may install them by doing : sh $ sudo apt-get install git $ curl -s http://getcomposer.org/installer | php

Then, you'll have to retrieve dibber's code and its dependencies. You may either fork this repository and then retrieve your forked code or if you just want to have a look at the code without being able to modify it you may simply do : sh $ git clone git://github.com/dibber-org/dibber.git $ cd dibber $ /path/to/composer.phar install $ chmod 777 module/Dibber/src/Dibber/Document/Hydrator/ module/Dibber/src/Dibber/Document/Proxy/

Do not forget you have to have a MongoDB server running. To configure the application so it can have access to it create a file : config/autoload/module.doctrine-mongo-odm.local.php and copy the doctrine.connection part of config/autoload/module.doctrine-mongo-odm.global.php in it with the right information so it would look like this : php <?php return [ 'doctrine' => [ 'connection' => [ 'odm_default' => [ 'server' => 'localhost', 'port' => '27017', 'user' => 'root', 'password' => 'mybadasspwd', 'dbname' => 'dibber', 'options' => [] ], ], ], ];

Pay attention to never commit your *.local.php configuration files as they are there only for your environnement.

You now have a working dibber, congratz ! If you have any question have a look at the mailing-list and/or ask there.

Dev guidelines

Workflow

As we're using git for versionning, you're asked to follow the Git workflow. For you it basically means that if you wish to contribute by coding you have to always send a pull request (even if you have commit access). So, the steps would be :

1. Fork the project,
2. Create a feature branch (name it wisely and prefix it with the issue number if there is any),
3. Code in it,
4. Send back a pull request.

Two other important branches are :

• The master branch is the latest stable release (ie: you never commit in it)
• The develop branch is the latest code in development (pull requests will be merged in it)

Also, i(jhuet)'m proposing to use Trello in conjunction of the GitHub issues page as a kanban system. That could allow us to easily determine who's working on what and validate the different steps required for a new feature to be completed. So far i'm using [Zapier](https://zapier.com] that automatically creates a Trello card when an issue is created (even though it's pulled every 5 hours only as i'm using the free version). Nonetheless, issues discussions should always happen on GitHub. Non-issue cards can still be created manually on Trello. Discussions about them would then happen there.

Coding standards

For now we'll borrow the coding standards used for Zend Framework 2 that you may find here.

Test coverage

It's still open to discussion, but so far i(jhuet)'m very interested in Atoum and would like to use it ASAP so we can start Test Driven Development.

Continuous integration

Once some unit tests will be created, continuous integration will be done thanks to Travis.

Design / Interface

Soon...

Translation

We'll certainly use Transifex when the time comes.