diff options
| -rw-r--r-- | contributing | 159 | ||||
| -rw-r--r-- | readme.rst | 160 |
2 files changed, 159 insertions, 160 deletions
diff --git a/contributing b/contributing new file mode 100644 index 000000000..0519b38cb --- /dev/null +++ b/contributing @@ -0,0 +1,159 @@ +########################### +Contributing to CodeIgniter +########################### + +CodeIgniter is a community driven project and accepts contributions of code +and documentation from the community. These contributions are made in the form +of Issues or `Pull Requests <http://help.github.com/send-pull-requests/>`_ on +the `EllisLab CodeIgniter repository +<https://github.com/EllisLab/CodeIgniter>`_ on GitHub. + +Issues are a quick way to point out a bug. If you find a bug or documentation +error in CodeIgniter then please check a few things first: + +- There is not already an open Issue +- The issue has already been fixed (check the develop branch, or look for + closed Issues) +- Is it something really obvious that you fix it yourself? + +Reporting issues is helpful but an even better approach is to send a Pull +Request, which is done by "Forking" the main repository and committing to your +own copy. This will require you to use the version control system called Git. + +********** +Guidelines +********** + +Before we look into how, here are the guidelines. If your Pull Requests fail +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 meet the `Style Guide +<http://codeigniter.com/user_guide/general/styleguide.html>`_, which is +essentially the `Allman indent style +<http://en.wikipedia.org/wiki/Indent_style#Allman_style>`_, underscores 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. + +Documentation +============= + +If you change anything that requires a change to documentation then you will +need to add it. New classes, methods, parameters, changing default values, etc +are all things that will require a change to documentation. The change-log +must also be updated for every change. Also PHPDoc blocks must be maintained. + +Compatibility +============= + +CodeIgniter is compatible with PHP 5.2.4 so all code supplied must stick to +this requirement. If PHP 5.3 or 5.4 functions or features are used then there +must be a fallback for PHP 5.2.4. + +Branching +========= + +CodeIgniter uses the `Git-Flow +<http://nvie.com/posts/a-successful-git-branching-model/>`_ branching model +which requires all pull requests to be sent to the "develop" branch. This is +where the next planned version will be developed. The "master" branch will +always contain the latest stable version and is kept clean so a "hotfix" (e.g: +an emergency security patch) can be applied to master to create a new version, +without worrying about other features holding it up. For this reason all +commits need to be made to "develop" and any sent to "master" will be closed +automatically. If you have multiple changes to submit, please place all +changes into their own branch on your fork. + +One thing at a time: A pull request should only contain one change. That does +not mean only one commit, but one change - however many commits it took. The +reason for this is that if you change X and Y but send a pull request for both +at the same time, we might really want X but disagree with Y, meaning we +cannot merge the request. Using the Git-Flow branching model you can create +new branches for both of these features and send two requests. + +Signing +======= +You must sign your work, certifying that you either wrote the work or +otherwise have the right to pass it on to an open source project. git makes +this trivial as you merely have to use `--signoff` on your commits to your +CodeIgniter fork. + +:: + + git commit --signoff + +or simply:: + + git commit -s + +This will sign your commits with the information setup in your git config, e.g. + + Signed-off-by: John Q Public <john.public@example.com> + +If you are using Tower there is a "Sign-Off" checkbox in the commit window. You +could even alias git commit to use the -s flag so you don’t have to think about +it. + +By signing your work in this manner, you certify to a "Developer's Certificate +or Origin". The current version of this certificate is in the `DCO.txt` file +in the root of this repository. + + +************ +How-to Guide +************ + +There are two ways to make changes, the easy way and the hard way. Either way +you will need to `create a GitHub account <https://github.com/signup/free>`_. + +Easy way GitHub allows in-line editing of files for making simple typo changes +and quick-fixes. This is not the best way as you are unable to test the code +works. If you do this you could be introducing syntax errors, etc, but for a +Git-phobic user this is good for a quick-fix. + +Hard way The best way to contribute is to "clone" your fork of CodeIgniter to +your development area. That sounds like some jargon, but "forking" on GitHub +means "making a copy of that repo to your account" and "cloning" means +"copying that code to your environment so you can work on it". + +#. Set up Git (Windows, Mac & Linux) +#. Go to the CodeIgniter repo +#. Fork it +#. Clone your CodeIgniter repo: git@github.com:<your-name>/CodeIgniter.git +#. Checkout the "develop" branch At this point you are ready to start making + changes. +#. Fix existing bugs on the Issue tracker after taking a look to see nobody + else is working on them. +#. Commit the files +#. Push your develop branch to your fork +#. Send a pull request http://help.github.com/send-pull-requests/ + +The Reactor Engineers will now be alerted about the change and at least one of +the team will respond. If your change fails to meet the guidelines it will be +bounced, or feedback will be provided to help you improve it. + +Once the Reactor Engineer handling your pull request is happy with it they +will post it to the internal EllisLab discussion area to be double checked by +the other Engineers and EllisLab developers. If nobody has a problem with the +change then it will be merged into develop and will be part of the next +release. Keeping your fork up-to-date + +Unlike systems like Subversion, Git can have multiple remotes. A remote is the +name for a URL of a Git repository. By default your fork will have a remote +named "origin" which points to your fork, but you can add another remote named +"codeigniter" which points to git://github.com/EllisLab/CodeIgniter.git. This +is a read-only remote but you can pull from this develop branch to update your +own. + +If you are using command-line you can do the following: + +#. git remote add codeigniter git://github.com/EllisLab/CodeIgniter.git +#. git pull codeigniter develop +#. git push origin develop + +Now your fork is up to date. This should be done regularly, or before you send +a pull request at least.
\ No newline at end of file diff --git a/readme.rst b/readme.rst index b211ad7cd..8628645c6 100644 --- a/readme.rst +++ b/readme.rst @@ -38,166 +38,6 @@ Installation Please see the `installation section <http://codeigniter.com/user_guide/installation/index.html>`_ of the CodeIgniter User Guide. -************ -Contributing -************ - -CodeIgniter is a community driven project and accepts contributions of code -and documentation from the community. These contributions are made in the form -of Issues or `Pull Requests <http://help.github.com/send-pull-requests/>`_ on -the `EllisLab CodeIgniter repository -<https://github.com/EllisLab/CodeIgniter>`_ on GitHub. - -Issues are a quick way to point out a bug. If you find a bug or documentation -error in CodeIgniter then please check a few things first: - -- There is not already an open Issue -- The issue has already been fixed (check the develop branch, or look for - closed Issues) -- Is it something really obvious that you fix it yourself? - -Reporting issues is helpful but an even better approach is to send a Pull -Request, which is done by "Forking" the main repository and committing to your -own copy. This will require you to use the version control system called Git. - -********** -Guidelines -********** - -Before we look into how, here are the guidelines. If your Pull Requests fail -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 meet the `Style Guide -<http://codeigniter.com/user_guide/general/styleguide.html>`_, which is -essentially the `Allman indent style -<http://en.wikipedia.org/wiki/Indent_style#Allman_style>`_, underscores 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. - -Documentation -============= - -If you change anything that requires a change to documentation then you will -need to add it. New classes, methods, parameters, changing default values, etc -are all things that will require a change to documentation. The change-log -must also be updated for every change. Also PHPDoc blocks must be maintained. - -Compatibility -============= - -CodeIgniter is compatible with PHP 5.2.4 so all code supplied must stick to -this requirement. If PHP 5.3 or 5.4 functions or features are used then there -must be a fallback for PHP 5.2.4. - -Branching -========= - -CodeIgniter uses the `Git-Flow -<http://nvie.com/posts/a-successful-git-branching-model/>`_ branching model -which requires all pull requests to be sent to the "develop" branch. This is -where the next planned version will be developed. The "master" branch will -always contain the latest stable version and is kept clean so a "hotfix" (e.g: -an emergency security patch) can be applied to master to create a new version, -without worrying about other features holding it up. For this reason all -commits need to be made to "develop" and any sent to "master" will be closed -automatically. If you have multiple changes to submit, please place all -changes into their own branch on your fork. - -One thing at a time: A pull request should only contain one change. That does -not mean only one commit, but one change - however many commits it took. The -reason for this is that if you change X and Y but send a pull request for both -at the same time, we might really want X but disagree with Y, meaning we -cannot merge the request. Using the Git-Flow branching model you can create -new branches for both of these features and send two requests. - -Signing -======= -You must sign your work, certifying that you either wrote the work or -otherwise have the right to pass it on to an open source project. git makes -this trivial as you merely have to use `--signoff` on your commits to your -CodeIgniter fork. - -:: - - git commit --signoff - -or simply:: - - git commit -s - -This will sign your commits with the information setup in your git config, e.g. - - Signed-off-by: John Q Public <john.public@example.com> - -If you are using Tower there is a "Sign-Off" checkbox in the commit window. You -could even alias git commit to use the -s flag so you don’t have to think about -it. - -By signing your work in this manner, you certify to a "Developer's Certificate -or Origin". The current version of this certificate is in the `DCO.txt` file -in the root of this repository. - - -************ -How-to Guide -************ - -There are two ways to make changes, the easy way and the hard way. Either way -you will need to `create a GitHub account <https://github.com/signup/free>`_. - -Easy way GitHub allows in-line editing of files for making simple typo changes -and quick-fixes. This is not the best way as you are unable to test the code -works. If you do this you could be introducing syntax errors, etc, but for a -Git-phobic user this is good for a quick-fix. - -Hard way The best way to contribute is to "clone" your fork of CodeIgniter to -your development area. That sounds like some jargon, but "forking" on GitHub -means "making a copy of that repo to your account" and "cloning" means -"copying that code to your environment so you can work on it". - -#. Set up Git (Windows, Mac & Linux) -#. Go to the CodeIgniter repo -#. Fork it -#. Clone your CodeIgniter repo: git@github.com:<your-name>/CodeIgniter.git -#. Checkout the "develop" branch At this point you are ready to start making - changes. -#. Fix existing bugs on the Issue tracker after taking a look to see nobody - else is working on them. -#. Commit the files -#. Push your develop branch to your fork -#. Send a pull request http://help.github.com/send-pull-requests/ - -The Reactor Engineers will now be alerted about the change and at least one of -the team will respond. If your change fails to meet the guidelines it will be -bounced, or feedback will be provided to help you improve it. - -Once the Reactor Engineer handling your pull request is happy with it they -will post it to the internal EllisLab discussion area to be double checked by -the other Engineers and EllisLab developers. If nobody has a problem with the -change then it will be merged into develop and will be part of the next -release. Keeping your fork up-to-date - -Unlike systems like Subversion, Git can have multiple remotes. A remote is the -name for a URL of a Git repository. By default your fork will have a remote -named "origin" which points to your fork, but you can add another remote named -"codeigniter" which points to git://github.com/EllisLab/CodeIgniter.git. This -is a read-only remote but you can pull from this develop branch to update your -own. - -If you are using command-line you can do the following: - -#. git remote add codeigniter git://github.com/EllisLab/CodeIgniter.git -#. git pull codeigniter develop -#. git push origin develop - -Now your fork is up to date. This should be done regularly, or before you send -a pull request at least. - ******* License ******* |