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
_______________________________________________
kallithea-general mailing list
[email protected]
http://lists.sfconservancy.org/mailman/listinfo/kallithea-general
