Community

Join the discussion

To discuss with the Werval community, post questions and get answers, join us at freenode, IRC channel ##werval.

If you have a question and need some answers, ask it on stackoverflow using the werval tag.

If you found a bug, want to request a new feature or enhancement or would like to contribute to Werval, keep reading.

Report bugs

If you encounter an issue, please report it by creating a new issue with as much detail as you can get.

Before doing so, please search for existing issues and make sure your bug hasn’t been reported yet.

Remember that you can paste programs output, error traces etc.. into the issue and attach log files, screenshots to it. Anything that could allow us to reproduce the bug in order to fix it is welcome!

If you happen to have some coding skills but don’t want to dive into Werval source code, a test-case that reproduce the bug would be awesome.

Request features & enhancements

Feature or enhancement requests are more than welcome. They are as important as bugs as they give the opportunity to discuss what’s in, what’s missing etc…​

Simply report them by creating a new issue describing the feature or enhancement you have in mind.

Propose patches

Werval is written using the Java language (but not limited to it, see the F.A.Q). The source code is managed using git. You’ll need to use theses two technologies for contributing new code to Werval.

Of course, the first step is to build werval from sources.

Once you’re confident the build is working on your computer, you’ll want a convy IDE supporting Java 8. Werval is built using Gradle that is supported by many IDEs, see the Gradle Tooling page at gradle.org.

We recommand Netbeans but IntelliJ IDEA or Eclipse will do. If you are adventurous, any text editor can be used.

Contribution workflow

We accept contributions as Github Pull Requests.

Pull requests let you tell others about changes you’ve pushed to a repository on GitHub. Once a pull request is sent, interested parties can review the set of changes, discuss potential modifications, and even push follow-up commits if necessary.

See the Using pull requests guide on Github Help.

Important
Development happens on the develop branch, remember to target it, not master, when sending pull requests.

If your contribution is related to an existing issue, please follow this Converting github issues into pull-requests guide.

Contribute documentation

If you want to contribute to the documentation effort, well that’s really good news!

The Werval documentation lies alongside the source code. It is written using the AsciiDoc format and processed using AsciiDoctor, here is the User Manual. All you need is a text editor.

Note
Documentation contribution workflow is the very same as for code contributions, see above.

The Werval build system generates a HTML version of the documentation. You should start by building Werval from the source, see above.

Once that the build pass on your computer, see the Werval Documentation guide.

Create modules

See the Writing Werval Modules guide.

Core Team workflow

We generally uses a Commit-Then-Review policy on most changes. This allows a reasonable high velocity of development.

Branching model

Courtesy of Vincent Driessen, we borrowed the git-flow branching model.

Git Flow

It looks more complicated than it is. Here are the guidelines;

  • Never commit to the master branch while developing!!

  • The develop branch is the equivalent of trunk in subversion.

  • Any changes that are not trivial, start a feature branch.

  • The following names are reserved for not feature branches; master, develop, hotfix/, release/

Day-to-day development revolves around the develop branch and it is this branch that you typically clone from our repository if you intend to contribute to Werval itself. If you create a new feature, or make some larger piece of refactoring, then please create a 'feature branch' (see article for details).

The release/ and hotfix/ branches are for release management only, and doesn’t affect most contributors from a commit perspective.

Tip

For convenience you should install and use the git-flow git extension that implement this branching model by adding git commands. You may find the git-flow cheatsheet helpful too. It is available in several languages.

Merging pull-requests

Github pull requests must be merged to the develop branch only.