kallithea Changeset - 653fee8db519

Changeset - 653fee8db519

Parent rev.

Child rev.

[Not reviewed]

default

0 1 0

Konstantin Veretennicov - 9 years ago 2016-06-15 21:09:03
kveretennicov@gmail.com

docs: mention preference for non-publishing repositories for pull requests

1 file changed with 9 insertions and 1 deletions:

docs/contributing.rst

0 comments (0 inline, 0 general)

docs/contributing.rst

➞

Show inline comments

@@ @@ -110,51 +110,59 @@ We try to support the most common modern @@
 to the extent it is feasible, IE8 is not.
 We primarily support Linux and OS X on the server side but Windows should also work.
 HTML templates should use 2 spaces for indentation ... but be pragmatic. We
 should use templates cleverly and avoid duplication. We should use reasonable
 semantic markup with element classes and IDs that can be used for styling and testing.
 We should only use inline styles in places where it really is semantic (such as
 ``display: none``).
 JavaScript must use ``;`` between/after statements. Indentation 4 spaces. Inline
 multiline functions should be indented two levels -- one for the ``()`` and one for
 ``{}``.
 Variables holding jQuery objects should be named with a leading ``$``.
 Commit messages should have a leading short line summarizing the changes. For
 bug fixes, put ``(Issue #123)`` at the end of this line.
 Use American English grammar and spelling overall. Use `English title case`_ for
 page titles, button labels, headers, and 'labels' for fields in forms.
 .. _English title case: https://en.wikipedia.org/wiki/Capitalization#Title_case
 Contributions will be accepted in most formats -- such as pull requests on
-bitbucket, something hosted on your own Kallithea instance, or patches sent by
+Bitbucket, something hosted on your own Kallithea instance, or patches sent by
 email to the `kallithea-general`_ mailing list.
 When contributing via Bitbucket, please make your fork of
 https://bitbucket.org/conservancy/kallithea/ `non-publishing`_ -- it is one of
 the settings on "Repository details" page. This ensures your commits are in
 "draft" phase and makes it easier for you to address feedback and for project
 maintainers to integrate your changes.
 .. _non-publishing: https://www.mercurial-scm.org/wiki/Phases#Publishing_Repository
 Make sure to test your changes both manually and with the automatic tests
 before posting.
 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 try to make sure we have consensus on the direction the project is taking.
 Everything non-sensitive should be discussed in public -- preferably on the
 mailing list.  We aim at having all non-trivial changes reviewed by at least
 one other core developer before pushing. Obvious non-controversial changes will
 be handled more casually.
 For now we just have one official branch ("default") and will keep it so stable
 that it can be (and is) used in production. Experimental changes should live
 elsewhere (for example in a pull request) until they are ready.
 "Roadmap"
 ---------
 We do not have a road map but are waiting for your contributions. Refer to the
 wiki_ for some ideas of places we might want to go -- contributions in these

0 comments (0 inline, 0 general)