Update & restructure contribution guide.

Signed-off-by:Master Yoda <jim_parry@bcit.ca>

application/Config/App.php

@@ -197,7 +197,7 @@ class App extends BaseConfig
 	|--------------------------------------------------------------------------
 	| The Debug Toolbar provides a way to see information about the performance
 	| and state of your application during that page display. By default it will
-	| be displayed under production environments, and will only display if
+	| NOT be displayed under production environments, and will only display if
 	| CI_DEBIG is true, since if it's not, there's not much to display anyway.
 	*/
 	public $toolbarEnabled = (ENVIRONMENT != 'production' && CI_DEBUG);

phpdoc.dist.xml

@@ -9,8 +9,8 @@
     </transformer>
     <files>
         <directory>./system</directory>
-        <ignore>vendor/*</ignore>
-        <ignore>test/*</ignore>
+        <ignore>./vendor/*</ignore>
+        <ignore>./tests/*</ignore>
         <ignore>Kint/*</ignore>
     </files>
 

user_guide_src/source/changelog.rst

@@ -9,51 +9,3 @@ Release Date: Not Released
 
 Rewrite
 
-Version 3.0.6
-=============
-
-Release Date: Mar 21, 2016
-
-Maintenance update.
-
-Version 3.0.0
-=============
-
-Release Date: April 24, 2015
-
-Initial release of V3
-
-Version 2.2.6
-=============
-
-Release Date: Oct 31, 2015
-
-Last release for V2. EOL.
-
-Version 2.0.0
-=============
-
-Release Date: January 28, 2011
-
-First release of V2
-
-Version 1.7.2
-=============
-
-Release Date: September 11, 2009
-
-Last release in the V1 line.
-
-Version 1.2
-===========
-
-Release Date: March 21, 2006
-
-First non-beta release
-
-Version Beta 1.0
-================
-
-Release Date: February 28, 2006
-
-First publicly released version.

user_guide_src/source/documentation/index.rst → user_guide_src/source/contributing/documentation.rst

@@ -101,102 +101,3 @@ create these with the following tab triggers::
 
 		SubSubSubSubSection (!)
 		"""""""""""""""""""""""
-
-
-
-
-********************
-Method Documentation
-********************
-
-When documenting class methods for third party developers, Sphinx provides
-directives to assist and keep things simple.  
-For example, consider the following ReST:
-
-.. code-block:: rst
-
-	.. php:class:: Some_class
-
-		.. php:method:: some_method ( $foo [, $bar [, $bat]])
-
-			This function will perform some action. The ``$bar`` array must contain
-			a something and something else, and along with ``$bat`` is an optional
-			parameter.
-
-			:param int $foo: the foo id to do something in
-			:param mixed $bar: A data array that must contain a something and something else
-			:param bool $bat: whether or not to do something
-			:returns: FALSE on failure, TRUE if successful
-			:rtype: bool
-
-			::
-
-				$this->load->library('some_class');
-
-				$bar = array(
-					'something'		=> 'Here is this parameter!',
-					'something_else'	=> 42
-				);
-
-				$bat = $this->some_class->should_do_something();
-
-				if ($this->some_class->some_method(4, $bar, $bat) === FALSE)
-				{
-					show_error('An Error Occurred Doing Some Method');
-				}
-
-			.. note:: Here is something that you should be aware of when using some_method().
-					For real.
-
-			See also :meth:`Some_class::should_do_something`
-
-
-		.. php:method:: should_do_something()
-
-			:returns: Whether or not something should be done
-			:rtype: bool
-
-
-It creates the following display:
-
-.. php:class:: Some_class
-
-
-	.. php:method:: some_method ( $foo [, $bar [, $bat]])
-
-		This function will perform some action. The ``$bar`` array must contain
-		a something and something else, and along with ``$bat`` is an optional
-		parameter.
-
-		:param int $foo: the foo id to do something in
-		:param mixed $bar: A data array that must contain a something and something else
-		:param bool $bat: whether or not to do something
-		:returns: FALSE on failure, TRUE if successful
-		:rtype: bool
-
-		::
-
-			$this->load->library('some_class');
-
-			$bar = array(
-				'something'		=> 'Here is this parameter!',
-				'something_else'	=> 42
-			);
-
-			$bat = $this->some_class->should_do_something();
-
-			if ($this->some_class->some_method(4, $bar, $bat) === FALSE)
-			{
-				show_error('An Error Occurred Doing Some Method');
-			}
-
-		.. note:: Here is something that you should be aware of when using some_method().
-				For real.
-
-		See also :meth:`Some_class::should_do_something`
-
-
-	.. php:method:: should_do_something()
-
-		:returns: Whether or not something should be done
-		:rtype: bool

user_guide_src/source/contributing/guidelines.rst

@@ -0,0 +1,113 @@
+=======================
+Contribution Guidelines
+=======================
+
+Your Pull Requests (PRs) need to meet our guidelines. If a PR fails
+to pass these guidelines, it will be declined and you will need to re-submit
+when you’ve made the changes. This might sound a bit tough, but it is required
+for us to maintain quality of the code-base.
+
+PHP Style
+=========
+
+All code must conform to our `Style Guide
+<./styleguide.html>`_, which is
+essentially the `Allman indent style
+<https://en.wikipedia.org/wiki/Indent_style#Allman_style>`_, with
+elaboration on naming and readable operators. 
+
+This makes certain that all code is the same format as the
+existing code and means it will be as readable as possible.
+
+Our Style Guide is similar to PSR-1 and PSR-2, from PHP-FIG,
+but not necessarily the same or compatible.
+
+Unit Testing
+============
+
+Unit testing is expected for all CodeIgniter components.
+We use PHPunit, and run unit tests using travis-ci
+for each PR submitted or changed.
+
+In the CodeIgniter project, there is a ``tests`` folder, with a structure that
+parallels that of ``system``.
+
+The normal practice would be to have a unit test class for each of the classes
+in ``system``, named appropriately. For instance, the ``BananaTest`` 
+class would test the ``Banana`` class. There will be occasions when 
+it is more convenient to have separate classes to test different functionality
+of a single CodeIgniter component.
+
+See the `PHPUnit website <https://phpunit.de/>`_ for more information.
+
+PHPdoc Comments
+===============
+
+Source code should be commented using PHPdoc comments blocks.
+Thie means implementation comments to explain potentially confusing sections 
+of code, and documentation comments before each public or protected
+class/interface/trait, method and variable.
+
+See the `phpDocumentor website <https://phpdoc.org/>`_ for more information.
+
+We use ``phpDocumentor2`` to generate the API documentation for the 
+framework, with configuration details in ``phpdoc.dist.xml`` in the project
+root.
+
+Documentation
+=============
+
+The User Guide is an essential component of the CodeIgniter framework.
+
+Each framework component or group of components needs a corresponding
+section in the User Guide. Some of the more fundamental components will
+show up in more than one place.
+
+Change Log
+==========
+
+The change-log, in the user guide root, needs to be kept up-to-date.
+
+See the `CodeIgniter 3 change log 
+<https://github.com/bcit-ci/CodeIgniter/blob/develop/user_guide_src/source/changelog.rst>`_ 
+for an example.
+
+PHP Compatibility
+=================
+
+CodeIgniter4 requires PHP 7.
+
+There is currently an issue with phpDocumentor and PHP7 ...
+
+phpDocumentor2 does not properly recognize the hinted return type in PHP7.
+In order to generate phpdocs for CI4, the return types in method signatures 
+have been commented out for now. They can be restored using a global search 
+& replace once phpDocumentor has addressed their issue.
+
+Desired: ``function banana(): fruit``
+Workaround: ``function banana()//: fruit``
+
+Or, for an interface...
+Desired: ``function banana(): fruit;``
+Workaround: ``function banana();//: fruit;``
+
+Backwards Compatibility
+=======================
+
+Generally, we aim to maintain backwards compatibility between minor
+versions of the framework. Any changes that break compatibility need
+a good reason to do so, and need to be pointed out in the
+`Upgrading <../installation/upgrading.html>`_ guide.
+
+CodeIgniter4 itself represents a significant backwards compatibility break
+with earlier versions of the framework.
+
+Mergeability
+============
+
+Your PRs need to be mergeable before they will be considered.
+
+We suggest that you synchronize your repository's ``develop`` branch with
+that in the main repository before submitting a PR.
+You will need to resolve any merge conflicts introduced by changes
+incorporated since you started working on your contribution.