Developement and Contribution Rules

Description

Things like codingstyle and the way contributions are accepted should be documented.

Some thoughts:

  • Code contribution is done via pull request

  • Respect existing code formatting - only format changes or added lines

  • Use spaces instead of tabs

  • Code cleanup only in separate commits and if development activity is low

  • Every commit links to an issue

  • Pull request should contain commits to one specific issue in a separate branch

Environment

None

Activity

Show:
nblock
June 9, 2015, 7:54 PM

I think the java style guide is a good solution, but I would not use an automatic code converter for each build. Just format all files once and run for example checkstyle regularly to find offending lines.

newlines: nothing in particular, vim and git complain when they encounter them.

regarding license, I updated the license comment and used the plain apache 2 license, but its ok to keep the files as is.

nblock
June 11, 2015, 6:02 AM

Requiring an issue for each pull request might be an overkill. The commits of a pull request should have a detailed commit message, so no information is lost. I'm thinking about documentation fixes, code cleanups, ….

Volker Voßkämper
June 11, 2015, 8:46 PM
Edited

Now we end up with a pull request named: Miscellaneous documentation fixes
which contained a branch named: jas-86
And your previous changes regarding document snippets are lost. (not really, it was at da61859)
You mixed documentation fixes an changes regarding in one commit pointing to
If there are more than one contributor or pull request at the same time, this is confusing in a way that no one can handle it.

This is a very good example to show that my proposed workflow is right

No commit without an issue #.
One feature branch regarding exactly one issue contained in a pull request with same name.
No other changes, corrections, etc in the same request.

All documentation fixes can go in one issue which is closed if a release will be done.

Code cleanup should not happen regularly. This confuses change reviews and can introduce errors.
It should be done only once, if the rules are clearly defined.
Then new changes should be watched not to violate the rules.

Volker Voßkämper
June 14, 2015, 7:00 PM

Proposal for a new Menu structure:

Overview -> Introduction
-> Usage
-> Screenshots
-> Installation
-> Changes
-> Files
-> ...
HowTo ...
Development -> Codingstyle
-> How to contribute
...

Volker Voßkämper
January 25, 2017, 5:58 PM

Contribution workflow should be forking-workflow using feature branches like described here:
https://www.atlassian.com/git/tutorials/comparing-workflows#forking-workflow

Assignee

Volker Voßkämper

Reporter

Volker Voßkämper

Labels

None

Components

Fix versions

Priority

Major
Configure