[Pkg-owncloud-commits] [owncloud-doc] 254/270: Update codingguidelines.rst

[David Prévot]

This is an automated email from the git hooks/post-receive script.

taffit pushed a commit to branch master
in repository owncloud-doc.

commit 0ea7523594c298611ce2d8eaec75d8bd1b7703e6
Author: Jos Poortvliet <jospoortvliet at gmail.com>
Date:   Thu Jul 24 22:04:10 2014 +0200

    Update codingguidelines.rst
    
    Add most of the coding info from http://owncloud.org/contribute - this is where it belongs. Will link to it from owncloud.org ;-)
    
    Of course if we agree it belongs on owncloud.org then we can make a dedicated page there. It at least won't fit on owncloud.org/contribute because of https://github.com/owncloud/www/issues/132
---
 developer_manual/general/codingguidelines.rst | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/developer_manual/general/codingguidelines.rst b/developer_manual/general/codingguidelines.rst
index da1b45e..2d74176 100644
--- a/developer_manual/general/codingguidelines.rst
+++ b/developer_manual/general/codingguidelines.rst
@@ -6,6 +6,18 @@ Coding Style & General Guidelines
 General
 -------
 
+* Ideally, discuss your plans on the `mailing list <http://mailman.owncloud.org/mailman/listinfo/devel>`_ to see if others want to work with you on it
+* We use `Github <http://github.com/owncloud>`_, please get an account there and clone the repositories you want to work on
+* Fixes go directly to master, nevertheless they need to be tested thoroughly
+* New features are always developed in a branch and only merged to master once they are fully done
+* Software should work. Only put features into master when they are complete. It's better to not have a feature instead of having one that works poorly.
+* When you are finished, use the merge request function on Github. The other developers will look at it and give you feedback. You can also post your merge request to the mailing list to let people know. See `the code review page for more information <../bugtracker/codereviews.html>`_
+* Decisions are made by consensus. We strive for making the best technical decisions and as nobody can know everything, we collaborate. That means a first negative comment might not be the final word, neither is positive feedback an immediate GO. ownCloud is built out of modular pieces (apps) and maintainers have a strong influence. In case of disagreement we consult other seasoned contributors.
+* We need a signed contributor agreement from you to commit into the core repository (apps don't need that). All the information is in our `Contributor agreement FAQ <http://owncloud.org/about/contributor-agreement>`_.
+
+
+Coding
+------
 * Maximum line-length of 80 characters
 * Use tabs to indent
 * A tab is 4 spaces wide
@@ -16,10 +28,8 @@ General
 * Unit tests
 * HTML should be HTML5 compliant
 * Check these `database performance tips <http://mailman.owncloud.org/pipermail/devel/2014-June/000262.html>`_
-* Software should work. Only put features into master when they are complete. It's better to not have a feature instead of having one that works poorly.
-* Regularly reset your installation to see how the first-run experience is like. And improve it.
 * When you ``git pull``, always ``git pull --rebase`` to avoid generating extra commits like: *merged master into master*
-* We need a signed contributor agreement from you to commit into the core repository (apps don't need that). All the information is in our `Contributor agreement FAQ <http://owncloud.org/about/contributor-agreement>`_.
+
 
 User interface
 --------------
@@ -28,6 +38,7 @@ User interface
 * User data is sacred. Provide undo instead of asking for confirmation - `which might be dismissed <http://www.alistapart.com/articles/neveruseawarning/>`_
 * The state of the application should be clear. If something loads, provide feedback.
 * Do not adapt broken concepts (for example design of desktop apps) just for the sake of consistency. We aim to provide a better interface, so let's find out how to do that!
+* Regularly reset your installation to see how the first-run experience is like. And improve it.
 * Ideally do `usability testing <http://jancborchardt.net/usability-in-free-software>`_ to know how people use the software.
 * For further UX principles, read `Alex Faaborg from Mozilla <http://uxmag.com/articles/quantifying-usability>`_.
 

-- 
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/pkg-owncloud/owncloud-doc.git