Table of Contents


Thanks for your interest in contributing to the project!

Before you start

Before you begin working on your contribution, it is always a good idea to let us know. We might have plans you should be aware of, or someone might already be working on the same thing. A great way to do this is to file an issue in our tracker.

Hang out in our chatroom if you can. We'll be able to assist with any questions you might have, and provide advice and code reviews at your request.

Finally, note that we can't promise to accept every patch, but rest assured that we'll never reject without an explanation. Some reasons we might reject a patch:

If you submit code we reserve the right to criticise it, and let you know so that you can make it the best that it can be. Please don't take this process personally! We judge code, but we don't judge people 8-)

Creating patches

We are pretty relaxed about how we receive contributions, and we'll let you know if what you send us is problematic. However the preferred way to submit contributions is:

  1. Clone the source repository using Mercurial: hg clone (tip: if you are submitting a bugfix, replace 'trunk' with the version you are fixing, such as '0.9').
  2. Make your changes to the files in the repository you just cloned.
  3. Ensure make test passes, and run changed files through luacheck to catch any simple mistakes.
  4. Run hg commit to commit your changes to your local repository (if this is the first time you have used Mercurial, you may want to set your public name in .hgrc).

Exporting single commits:

  1. Run hg export tip > short-patch-description.patch

Exporting multiple commits:

  1. Run hg bundle short-patch-description.hg


Small commits

Try to keep individual commits small, and avoid doing multiple things in one commit (like fixing two different bugs, or implementing two different features). Make multiple commits if you have to.

Commit messages

By convention, our commit messages are a single line of text (commits that need a lot of description should probably be split), and commit messages begin with the name of the plugin(s) or core component they are modifying. For example:

   mod_ping: Implement timeout feature. Fixes #NNN.

Sending patches

Email the patch or bundle file to the prosody-dev mailing list, or simply to us at If the patch fixes a bug, please include the issue number.