...

In most repositories - unless you are fixing an emergency bug - you should branch of develop and merge back to develop in your pull request.  Any repository that uses a different flow should detail so in the README.md at the root of the repository.  If multiple develop branches exist and you are unsure which branch one to use, contact ask the  maintainersmaintainers.

Talk English

Please remember to use English everywhere:

...

Though we understand it's sometimes not easy, we do appreciate it if you pay some attention to correct spelling.  Especially when it comes to the code where correcting spelling errors post factum can introduce breaking changes.  A resource like Dictionary.com can be helpful.

Additional resources Resource files for other languages are welcomed, but please ensure they are correct and complete if you include them.

...

All repositories (should) have their equivalent JIRA project.  See if there's no JIRA issue yet matching with your intentions and If necessary report create your own.  This allows other developers to get involved more easily and also serves as a great help for generating the release notes.

...

Code style & copyright

Most contributors use IntelliJ IDEA as their favourite IDE and most repositories include the .idea project directory.  Code style settings and copyright should be attached to the project so it should be really easy to apply them.

...

If you code depends on different module configurations, you should test different configurations in separate integration tests.  As a general rule, modules should have have some integration tests that bootstraps bootstrap Across context configurations and verifies verify the exposed services, testing .  Testing correct bootstrapping of a module is an absolute minimum.

...

Test classes that should be run against external resources (databases) should start with IT*.  This ensures they will executed execute in the Maven verify phase, after the other unit tests and .  This will also ensure that our build agents run the tests against the different DBMS implementations.  You can find more information on this in the old documentation about integration testing.

...

Some modules include one or more test projects that run start a website and run automated acceptance tests against it.  This is advised and we might insist on it for functionality that is very UI driven.  Though not an absolute restriction, these acceptance tests are usually executed using CWB. 

Documentation

We consider solid documentation absolutely vital.  It cannot be expected that all developers to know the ins and outs of every module, and in a fast evolving landscape reliable documentation should be a beacon of trust.  

...

Geared towards all contributors and source-code reading developers: all .  All public methods and classes should include decent Javadoc.  Whenever you modify a class and do more than cosmetic changes, add yourself as an author with your full name.

Additional inline documentation is comments are optional but very welcome.  Just remember to write it in English as well.

...

The reference documentation is usually generated from AsciiDoc in the project source folder (search for index.adoc).  It should contain the explanation of all features that a module provides as well as the configuration options and inter-module dependencies involved.  Whenever you add a new feature or configuration option, you should update the reference documentation as well.  Reference documentation should really be as complete as possible, without delving in to too many implementation details.

Reference documentation is not the same as tutorials.  The reference documentation should give as good as possible a view of the functionality, without necessarily going into a structured explanation of how to achieve something.  If you want to write a tutorial we will gladly publish or link it on the Confluence site.

...

This is the central hub that connects all other documentation.  The Confluence pages are usually managed by the module maintainers , but any registered user can comment.

...

Geared towards contributors that use the Bitbucket repositories as entry point.  Apart from specific build instructions and base copyright rules, the readme should mostly refer back to the related Confluence documentationsite.

Unless you change the build instructions, you will rarely need to make changes to this file.

...

Have some time to spare and want to help improve Across?  The JIRA projects for both core and the standard modules have lots of issues in the backlog you can get started on.  We'd advise you to start with something small however (eg a simple bugfix).  Contact the issue reporter (either directly or through the issue comments ) if you need more information.

...

Following the guidelines requires a bit more effort, but it will make it more likely your pull request will be accepted and will greatly help in maintaining a high standard for our projects.

...