Draft proposal, Kallithea coding/contribution guideline

[Mads Kiilerich]

Here is a dump of my thoughts about how we should deal with development 
and process - this is pretty much what have been guiding my 
contributions and management of the project. This is mainly a starting 
point, describing how we do it now. We can always discuss and change it. 
Do you have any initial thoughts or comments?


Kallithea is GPLv3 and we assume all contributions are made by the 
committer/contributor and under GPLv3 unless explicitly stated. We do 
care about preservation of copyright and license information for 
existing code that is brought into the project.

For coding/formatting standard, we are currently using a mix of 
Mercurial (http://mercurial.selenic.com/wiki/CodingStyle), pep8, and 
consistency with existing code. (We would like to have some tool that 
could fix the most trivial formatting inconsistencies.)

We only support Python 2.x >= 2.6. For now we don't care about Python 3 
compatibility.

We try to support the most common modern web browsers. IE8 is still 
supported to the extent it is feasible but might be the next candidate 
for elimination in a year.

Html templates should use 2 space for indentation ... but be pragmatic. 
We should use templates and avoid duplication. We should use reasonable 
semantic markup with classes and ids that can be used for styling and 
testing. We should only use inline styles in places where it really is 
semantic (default value of display etc).

Javascript should use ; between/after statements. Indentation 4 spaces. 
Inline multiline functions should be indented two levels - one for the 
() and one for {}. jQuery value arrays should have a leading $.

Contributions will be accepted in most formats - such as pull requests 
on bitbucket, something hosted on your own Kallithea, or patches sent by 
mail to the kallithea-general mailing list . We care about quality and 
review and keeping a clean repository history. We might give feedback 
that requests polishing contributions until they are "perfect". We might 
also rebase and collapse and make minor adjustments to your changes when 
we apply them.

We aim at having major changes reviewed by two core developers to make 
sure we have consensus on the direction the project is taking - obvious 
non-controversial changes will be handled more casually.

For now we just have one official branch ("default") and try to keep it 
so stable that it can (and is) used in production. Experimental changes 
should live elsewhere until they are ready.

/Mads