Skip to content
This repository was archived by the owner on Jan 1, 2020. It is now read-only.

Commit bc04c3a

Browse files
weierophinneyweierophinney
committed
Merge branch 'hotfix/379'
Close #379
2 parents 1b8b1d7 + a5cad2e commit bc04c3a

File tree

2 files changed

+263
-0
lines changed

2 files changed

+263
-0
lines changed

‎CONDUCT.md‎

Lines changed: 43 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,43 @@
1+
# Contributor Code of Conduct
2+
3+
The Zend Framework project adheres to [The Code Manifesto](http://codemanifesto.com)
4+
as its guidelines for contributor interactions.
5+
6+
## The Code Manifesto
7+
8+
We want to work in an ecosystem that empowers developers to reach their
9+
potential — one that encourages growth and effective collaboration. A space that
10+
is safe for all.
11+
12+
A space such as this benefits everyone that participates in it. It encourages
13+
new developers to enter our field. It is through discussion and collaboration
14+
that we grow, and through growth that we improve.
15+
16+
In the effort to create such a place, we hold to these values:
17+
18+
1. **Discrimination limits us.** This includes discrimination on the basis of
19+
race, gender, sexual orientation, gender identity, age, nationality, technology
20+
and any other arbitrary exclusion of a group of people.
21+
2. **Boundaries honor us.** Your comfort levels are not everyone’s comfort
22+
levels. Remember that, and if brought to your attention, heed it.
23+
3. **We are our biggest assets.** None of us were born masters of our trade.
24+
Each of us has been helped along the way. Return that favor, when and where
25+
you can.
26+
4. **We are resources for the future.** As an extension of #3, share what you
27+
know. Make yourself a resource to help those that come after you.
28+
5. **Respect defines us.** Treat others as you wish to be treated. Make your
29+
discussions, criticisms and debates from a position of respectfulness. Ask
30+
yourself, is it true? Is it necessary? Is it constructive? Anything less is
31+
unacceptable.
32+
6. **Reactions require grace.** Angry responses are valid, but abusive language
33+
and vindictive actions are toxic. When something happens that offends you,
34+
handle it assertively, but be respectful. Escalate reasonably, and try to
35+
allow the offender an opportunity to explain themselves, and possibly correct
36+
the issue.
37+
7. **Opinions are just that: opinions.** Each and every one of us, due to our
38+
background and upbringing, have varying opinions. The fact of the matter, is
39+
that is perfectly acceptable. Remember this: if you respect your own
40+
opinions, you should respect the opinions of others.
41+
8. **To err is human.** You might not intend it, but mistakes do happen and
42+
contribute to build experience. Tolerate honest mistakes, and don't hesitate
43+
to apologize if you make one yourself.

‎CONTRIBUTING.md‎

Lines changed: 220 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,220 @@
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: [email protected]
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/ZendSkeletonApplication/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 [[email protected]](mailto:[email protected]) 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+
## RUNNING TESTS
38+
39+
First, use [Composer](https://getcomposer.org) to install all dependencies:
40+
41+
```bash
42+
$ composer install
43+
```
44+
45+
Make sure that `zendframework/zend-test` is installed:
46+
47+
```bash
48+
$ composer require --dev zendframework/zend-test
49+
```
50+
51+
To run tests:
52+
53+
```bash
54+
$ composer test
55+
```
56+
57+
You can turn on conditional tests with the `phpunit.xml` file.
58+
To do so:
59+
60+
- Copy `phpunit.xml.dist` file to `phpunit.xml`
61+
- Edit `phpunit.xml` to enable any specific functionality you
62+
want to test, as well as to provide test values to utilize.
63+
64+
## Running Coding Standards Checks
65+
66+
First, ensure you've installed dependencies via composer:
67+
68+
```bash
69+
$ composer require --dev squizlabs/php_codesniffer
70+
```
71+
72+
To run CS checks only:
73+
74+
```console
75+
$ composer cs-check
76+
```
77+
78+
To attempt to automatically fix common CS issues:
79+
80+
```console
81+
$ composer cs-fix
82+
```
83+
84+
If the above fixes any CS issues, please re-run the tests to ensure
85+
they pass, and make sure you add and commit the changes after verification.
86+
87+
## Recommended Workflow for Contributions
88+
89+
Your first step is to establish a public repository from which we can
90+
pull your work into the master repository. We recommend using
91+
[GitHub](https://github.com), as that is where the component is already hosted.
92+
93+
1. Setup a [GitHub account](http://github.com/), if you haven't yet
94+
2. Fork the repository (http://github.com/zendframework/ZendSkeletonApplication)
95+
3. Clone the canonical repository locally and enter it.
96+
97+
```bash
98+
$ git clone https://github.com/zendframework/ZendSkeletonApplication.git
99+
$ cd ZendSkeletonApplication
100+
```
101+
102+
4. Add a remote to your fork; substitute your GitHub username in the command
103+
below.
104+
105+
```bash
106+
$ git remote add {username} [email protected]:{username}/ZendSkeletonApplication.git
107+
$ git fetch {username}
108+
```
109+
110+
### Keeping Up-to-Date
111+
112+
Periodically, you should update your fork or personal repository to
113+
match the canonical ZF repository. Assuming you have setup your local repository
114+
per the instructions above, you can do the following:
115+
116+
117+
```bash
118+
$ git checkout master
119+
$ git fetch origin
120+
$ git rebase origin/master
121+
# OPTIONALLY, to keep your remote up-to-date -
122+
$ git push {username} master:master
123+
```
124+
125+
If you're tracking other branches -- for example, the "develop" branch, where
126+
new feature development occurs -- you'll want to do the same operations for that
127+
branch; simply substitute "develop" for "master".
128+
129+
### Working on a patch
130+
131+
We recommend you do each new feature or bugfix in a new branch. This simplifies
132+
the task of code review as well as the task of merging your changes into the
133+
canonical repository.
134+
135+
A typical workflow will then consist of the following:
136+
137+
1. Create a new local branch based off either your master or develop branch.
138+
2. Switch to your new local branch. (This step can be combined with the
139+
previous step with the use of `git checkout -b`.)
140+
3. Do some work, commit, repeat as necessary.
141+
4. Push the local branch to your remote repository.
142+
5. Send a pull request.
143+
144+
The mechanics of this process are actually quite trivial. Below, we will
145+
create a branch for fixing an issue in the tracker.
146+
147+
```bash
148+
$ git checkout -b hotfix/9295
149+
Switched to a new branch 'hotfix/9295'
150+
```
151+
152+
... do some work ...
153+
154+
155+
```bash
156+
$ git commit
157+
```
158+
159+
... write your log message ...
160+
161+
162+
```bash
163+
$ git push {username} hotfix/9295:hotfix/9295
164+
Counting objects: 38, done.
165+
Delta compression using up to 2 threads.
166+
Compression objects: 100% (18/18), done.
167+
Writing objects: 100% (20/20), 8.19KiB, done.
168+
Total 20 (delta 12), reused 0 (delta 0)
169+
To ssh://[email protected]/{username}/ZendSkeletonApplication.git
170+
b5583aa..4f51698 HEAD -> master
171+
```
172+
173+
To send a pull request, you have two options.
174+
175+
If using GitHub, you can do the pull request from there. Navigate to
176+
your repository, select the branch you just created, and then select the
177+
"Pull Request" button in the upper right. Select the user/organization
178+
"zendframework" as the recipient.
179+
180+
If using your own repository - or even if using GitHub - you can use `git
181+
format-patch` to create a patchset for us to apply; in fact, this is
182+
**recommended** for security-related patches. If you use `format-patch`, please
183+
send the patches as attachments to:
184+
185+
- [email protected] for patches without security implications
186+
- [email protected] for security patches
187+
188+
#### What branch to issue the pull request against?
189+
190+
Which branch should you issue a pull request against?
191+
192+
- For fixes against the stable release, issue the pull request against the
193+
"master" branch.
194+
- For new features, or fixes that introduce new elements to the public API (such
195+
as new public methods or properties), issue the pull request against the
196+
"develop" branch.
197+
198+
### Branch Cleanup
199+
200+
As you might imagine, if you are a frequent contributor, you'll start to
201+
get a ton of branches both locally and on your remote.
202+
203+
Once you know that your changes have been accepted to the master
204+
repository, we suggest doing some cleanup of these branches.
205+
206+
- Local branch cleanup
207+
208+
```bash
209+
$ git branch -d <branchname>
210+
```
211+
212+
- Remote branch removal
213+
214+
```bash
215+
$ git push {username} :<branchname>
216+
```
217+
218+
## Conduct
219+
220+
Please see our [CONDUCT.md](CONDUCT.md) to understand expected behavior when interacting with others in the project.

0 commit comments

Comments
 (0)