Please follow the following guidelines for development:



git clone
cd engine
git checkout dev
# Optional with Docker Machine
docker-machine create --driver virtualbox mesg-dev
eval $(docker-machine env mesg-dev)
# End optional
docker swarm init
docker network create --driver overlay engine --label com.docker.stack.namespace=engine

# Go get a coffee, it will take from 5min to 30min.

That's it, you have the MESG Engine ready and already running.


git clone
cd cli
npm install


Run all tests with code coverage

go test -cover -v ./...

Debugging on OS X

xcode-select --install
go get -u

If the debugger still doesn't work, try the following:

cd $GOPATH/src/
make install



All developments should be associated with one branch and one Pull Request.

Branch should start with the type of development followed by a description of this development:

  • feature/xxx
  • bug/xxx
  • refactoring/xxx
  • perf/xxx

All new branches should be created based on the dev branch, not the master.

Make sure to follow this pattern.


If a development is doing multiple things, refactoring, perf and feature for example, create different branches for this with different Pull Requests. Of course, these branches can depend one to another.

  • Feature = Forum + Pull Request
  • Bug = Github Issues + Pull Request


Every feature needs to be discussed to avoid chaos and to make sure that they are actually relevant.

Product roadmap

The list of all features to implement can be found on the associated Monday Board.


To brainstorm about new features you should create a new post on the forum on the relevant category with the tag Proposal and details about this feature.

You can find all proposals here. Also make sure that when these proposals are accepted and merged, they are resolved on the forum.


Bugs needs to be tracked on Github.

Test to reproduce

When fixing a bug, make sure you can reproduce it. The best way is to write a test that reproduces the bug and then fix the code to have the test green. This ensures that the bug is actually fixed and no regressions will occur.


When development is mature enough, you can create a Pull Request on Github (if you want early feedback on a work in progress use the Draft Pull Request option).

Then select the different reviewers for this Pull Request.

Try as much as possible to have Pull Requests with fast review, it's better to have 10 small Pull Requests easy to review than one big hard to review.


If a Pull Request has too many comments or take too long to merge, that's a good sign that this Pull Request is either too big or was not planned and will probably make the team loose a lot of time, so don't be scared to put your Pull Request onhold or even delete it and get back to it when there is a better understanding of what should be done.

Review a Pull Request from the community

If you want to review a Pull Request from the community you can have a look at this guide:


Before merging you must make sure that all criteria is valid:

  • everything is green on the Pull Request
  • all discussions are resolved
  • merge to the dev



  • Create a Pull Request with the new version and the update the to dev
  • Merge the previous Pull Request in the dev branch
  • Create a Pull Request from dev to master
  • Wait for CI to finish
  • Merge the previous Pull Request in the master branch
  • Tag the master with the latest version of the file
  • Check that the new docker image is uploaded to DockerHub
  • Update the Github's release note with the Changelog of this version
  • Follow the publication process
  • Add to the changelog and the GitHub release the link to the forum's release notes


  • To query all of the latest Pull Requests to build the changelog: is:pr is:closed merged:2018-10-05..2018-11-03 base:dev or use github-changelog-generator.
Last Updated: 7/1/2019, 11:47:44 AM