vendor/zendframework/zend-i18n-resources/CONTRIBUTING.md

   1 # CONTRIBUTING
   2
   3 ## RESOURCES
   4
   5 If you wish to contribute to Zend Framework, please be sure to
   6 read/subscribe to the following resources:
   7
   8  -  [Coding Standards](https://github.com/zendframework/zf2/wiki/Coding-Standards)
   9  -  [Contributor's Guide](http://framework.zend.com/participate/contributor-guide)
  10  -  ZF Contributor's mailing list:
  11     Archives: http://zend-framework-community.634137.n4.nabble.com/ZF-Contributor-f680267.html
  12     Subscribe: zf-contributors-subscribe@lists.zend.com
  13  -  ZF Contributor's IRC channel:
  14     #zftalk.dev on Freenode.net
  15
  16 If you are working on new features or refactoring [create a proposal](https://github.com/zendframework/zend-i18n-resources/issues/new).
  17
  18 ## Reporting Potential Security Issues
  19
  20 If you have encountered a potential security vulnerability, please **DO NOT** report it on the public
  21 issue tracker: send it to us at [zf-security@zend.com](mailto:zf-security@zend.com) instead.
  22 We will work with you to verify the vulnerability and patch it as soon as possible.
  23
  24 When reporting issues, please provide the following information:
  25
  26 - Component(s) affected
  27 - A description indicating how to reproduce the issue
  28 - A summary of the security vulnerability and impact
  29
  30 We request that you contact us via the email address above and give the project
  31 contributors a chance to resolve the vulnerability and issue a new release prior
  32 to any public exposure; this helps protect users and provides them with a chance
  33 to upgrade and/or update in order to protect their applications.
  34
  35 For sensitive email communications, please use [our PGP key](http://framework.zend.com/zf-security-pgp-key.asc).
  36
  37 ## Recommended Workflow for Contributions
  38
  39 Your first step is to establish a public repository from which we can
  40 pull your work into the master repository. We recommend using
  41 [GitHub](https://github.com), as that is where the component is already hosted.
  42
  43 1. Setup a [GitHub account](http://github.com/), if you haven't yet
  44 2. Fork the repository (http://github.com/zendframework/zend-i18n-resources)
  45 3. Clone the canonical repository locally and enter it.
  46
  47    ```console
  48    $ git clone git://github.com:zendframework/zend-i18n-resources.git
  49    $ cd zend-i18n-resources
  50    ```
  51
  52 4. Add a remote to your fork; substitute your GitHub username in the command
  53    below.
  54
  55    ```console
  56    $ git remote add {username} git@github.com:{username}/zend-i18n-resources.git
  57    $ git fetch {username}
  58    ```
  59
  60 ### Keeping Up-to-Date
  61
  62 Periodically, you should update your fork or personal repository to
  63 match the canonical ZF repository. Assuming you have setup your local repository
  64 per the instructions above, you can do the following:
  65
  66
  67 ```console
  68 $ git checkout master
  69 $ git fetch origin
  70 $ git rebase origin/master
  71 # OPTIONALLY, to keep your remote up-to-date -
  72 $ git push {username} master:master
  73 ```
  74
  75 If you're tracking other branches -- for example, the "develop" branch, where
  76 new feature development occurs -- you'll want to do the same operations for that
  77 branch; simply substitute  "develop" for "master".
  78
  79 ### Working on a patch
  80
  81 We recommend you do each new feature or bugfix in a new branch. This simplifies
  82 the task of code review as well as the task of merging your changes into the
  83 canonical repository.
  84
  85 A typical workflow will then consist of the following:
  86
  87 1. Create a new local branch based off either your master or develop branch.
  88 2. Switch to your new local branch. (This step can be combined with the
  89    previous step with the use of `git checkout -b`.)
  90 3. Do some work, commit, repeat as necessary.
  91 4. Push the local branch to your remote repository.
  92 5. Send a pull request.
  93
  94 The mechanics of this process are actually quite trivial. Below, we will
  95 create a branch for fixing an issue in the tracker.
  96
  97 ```console
  98 $ git checkout -b hotfix/9295
  99 Switched to a new branch 'hotfix/9295'
 100 ```
 101
 102 ... do some work ...
 103
 104
 105 ```console
 106 $ git commit
 107 ```
 108
 109 ... write your log message ...
 110
 111
 112 ```console
 113 $ git push {username} hotfix/9295:hotfix/9295
 114 Counting objects: 38, done.
 115 Delta compression using up to 2 threads.
 116 Compression objects: 100% (18/18), done.
 117 Writing objects: 100% (20/20), 8.19KiB, done.
 118 Total 20 (delta 12), reused 0 (delta 0)
 119 To ssh://git@github.com/{username}/zend-i18n-resources.git
 120    b5583aa..4f51698  HEAD -> master
 121 ```
 122
 123 To send a pull request, you have two options.
 124
 125 If using GitHub, you can do the pull request from there. Navigate to
 126 your repository, select the branch you just created, and then select the
 127 "Pull Request" button in the upper right. Select the user/organization
 128 "zendframework" as the recipient.
 129
 130 If using your own repository - or even if using GitHub - you can use `git
 131 format-patch` to create a patchset for us to apply; in fact, this is
 132 **recommended** for security-related patches. If you use `format-patch`, please
 133 send the patches as attachments to:
 134
 135 -  zf-devteam@zend.com for patches without security implications
 136 -  zf-security@zend.com for security patches
 137
 138 #### What branch to issue the pull request against?
 139
 140 Which branch should you issue a pull request against?
 141
 142 - For fixes against the stable release, issue the pull request against the
 143   "master" branch.
 144 - For new features, or fixes that introduce new elements to the public API (such
 145   as new public methods or properties), issue the pull request against the
 146   "develop" branch.
 147
 148 ### Branch Cleanup
 149
 150 As you might imagine, if you are a frequent contributor, you'll start to
 151 get a ton of branches both locally and on your remote.
 152
 153 Once you know that your changes have been accepted to the master
 154 repository, we suggest doing some cleanup of these branches.
 155
 156 -  Local branch cleanup
 157
 158    ```console
 159    $ git branch -d <branchname>
 160    ```
 161
 162 -  Remote branch removal
 163
 164    ```console
 165    $ git push {username} :<branchname>
 166    ```