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 (more information) :

• 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 pour la persistance des données
• 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

[ '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](https://groups.google.com/forum/#!forum/dibber) and/or ask there. #### Dev guidelines ##### Workflow As we're using git for versionning, you're asked to follow the [Git workflow](http://nvie.com/posts/a-successful-git-branching-model/). 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](https://trello.com/board/development/502979250e2623863414d33e) in conjunction of the GitHub issues page as a [kanban](https://en.wikipedia.org/wiki/Kanban_(development) 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](http://framework.zend.com/wiki/display/ZFDEV2/Coding+Standards). ##### Test coverage [Atoum](https://github.com/mageekguy/atoum/) is used to make unit tests. As much as possible try to think [Test Driven Development](http://en.wikipedia.org/wiki/Test-driven_development) when you dev and provide unit tests for the pull requests you'll make. To retrieve Atoum as a dependency with composer, `cd` in the root directory of the project and : ``` sh $ /path/to/composer.phar --dev update ``` All tests are in the `/tests` directory. To run them `cd` in the root directory of the project and : ``` sh $ bin/tests.sh ``` It will run all tests and tell you wich ones pass and wich ones don't. You can find some help on [how to use it here](https://github.com/geraldcroes/atoum-s-documentation/blob/master/Contents/chapter1.md). ##### Continuous integration Continuous integration will be done thanks to [Travis](http://travis-ci.org/). ### Design / Interface Soon... ### Translation We'll certainly use [Transifex](https://www.transifex.net/) when the time comes.