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

@@ @@ -122,27 +122,35 @@ multiline functions should be indented t @@
 ``{}``.
 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

0 comments (0 inline, 0 general)