Skip to content

Commit fed2127

Browse files
otengkwameotengkwame
committed
✨ add documents that supports open source contribution
Signed-off-by: otengkwame <[email protected]>
1 parent 520e6b9 commit fed2127

File tree

5 files changed

+228
-4
lines changed

5 files changed

+228
-4
lines changed

‎.gitattributes‎

Lines changed: 20 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,20 @@
1+
2+
# This file tells which files and directories should be ignored and
3+
# NOT downloaded when using composer to pull down a project with
4+
# the --prefer-dist option selected. Used to remove development
5+
# specific files so user has a clean download.
6+
7+
# git files
8+
/.gitattributes export-ignore
9+
/tests export-ignore
10+
/.travis.yml export-ignore
11+
/phpunit.xml export-ignore
12+
13+
# Don't give project files
14+
.github/ export-ignore
15+
contributing/ export-ignore
16+
.editorconfig export-ignore
17+
CODE_OF_CONDUCT.md export-ignore
18+
CONTRIBUTING.md export-ignore
19+
SECURITY.md export-ignore
20+
webby-readme.png export-ignore

‎CODE_OF_CONDUCT.md‎

Lines changed: 46 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,46 @@
1+
# Contributor Covenant Code of Conduct
2+
3+
## Our Pledge
4+
5+
In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
6+
7+
## Our Standards
8+
9+
Examples of behavior that contributes to creating a positive environment include:
10+
11+
* Using welcoming and inclusive language
12+
* Being respectful of differing viewpoints and experiences
13+
* Gracefully accepting constructive criticism
14+
* Focusing on what is best for the community
15+
* Showing empathy towards other community members
16+
17+
Examples of unacceptable behavior by participants include:
18+
19+
* The use of sexualized language or imagery and unwelcome sexual attention or advances
20+
* Trolling, insulting/derogatory comments, and personal or political attacks
21+
* Public or private harassment
22+
* Publishing others' private information, such as a physical or electronic address, without explicit permission
23+
* Other conduct which could reasonably be considered inappropriate in a professional setting
24+
25+
## Our Responsibilities
26+
27+
Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
28+
29+
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
30+
31+
## Scope
32+
33+
This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
34+
35+
## Enforcement
36+
37+
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project lead at [email protected]. The project lead will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project lead is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
38+
39+
Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
40+
41+
## Attribution
42+
43+
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
44+
45+
[homepage]: http://contributor-covenant.org
46+
[version]: http://contributor-covenant.org/version/1/4/

‎CONTRIBUTING.md‎

Lines changed: 131 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,131 @@
1+
# How to Contribute
2+
3+
Webby (sylynder/engine) 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 [sylynder/engine repository](https://github.com/sylynder/engine) on GitHub.
4+
5+
Issues are a quick way to point out a bug. If you find a bug or documentation error in sylynder/engine then please check a few things first:
6+
7+
1. There is not already an open issue
8+
2. The issue has already been fixed (check the develop branch, or look for closed Issues)
9+
3. Is it something really obvious that you can fix yourself?
10+
11+
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.
12+
13+
## Guidelines
14+
15+
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.
16+
17+
### Coding Standards
18+
19+
- [PSR-12](https://www.php-fig.org/psr/psr-12/) is in favour, even though not all might be adhered to, a little help is provided below.
20+
- Code MUST use tabs for indenting, 4 spaces can also be allowed but we are looking at not getting a messy code base, so please try your best and stick to it.
21+
- A class opening `{` must be on the next line.
22+
- A method or function opening `{` must be on the next line.
23+
- Class names MUST be declared in [StudlyCaps](http://en.wikipedia.org/wiki/CamelCase), e.g., `Class FooBar { }`.
24+
- Variable names
25+
- In classes MUST be declared in [camelCase](http://en.wikipedia.org/wiki/CamelCase), e.g., `$fooBar`.
26+
- Variable names declared in helper functions MUST be in [snake case](https://en.wikipedia.org/wiki/Snake_case) like this `$some_variable`.
27+
- Function names
28+
- In classes MUST be declared in [camelCase](http://en.wikipedia.org/wiki/CamelCase), e.g., `function fooBar() { }`
29+
- Helper function name MUST be declared using [snake case](https://en.wikipedia.org/wiki/Snake_case), e.g., `function some_function() { }`.
30+
31+
### Documentation
32+
33+
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. We are
34+
looking forward to modifying the code base to reflect the new PHP 8 syntax from time to time
35+
36+
### Compatibility
37+
38+
Webby recommends PHP 8.1 or newer to be used, but it should be
39+
compatible with PHP 8.0 so all code supplied must stick to this
40+
requirement.
41+
42+
## How-to Guide
43+
44+
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).
45+
46+
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.
47+
48+
Hard way The best way to contribute is to "clone" your fork of sylynder/engine 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".
49+
50+
1. [Set up Git](https://help.github.com/en/articles/set-up-git) (Windows, Mac & Linux)
51+
2. Go to the [sylynder/engine](https://github.com/sylynder/engine)
52+
3. Fork the develop [branch](https://help.github.com/en/articles/fork-a-repo)
53+
4. [Clone](https://help.github.com/en/articles/fetching-a-remote#clone) your forked sylynder/engine repo: https://github.com/<your-name>/engine.git
54+
5. Checkout the "develop" branch. At this point you are ready to start making changes.
55+
6. Fix bugs on the Issue tracker after taking a look to see nobody else is working on them.
56+
7. [Commit](https://help.github.com/en/articles/adding-a-file-to-a-repository-using-the-command-line) the files
57+
8. [Push](https://help.github.com/en/articles/pushing-to-a-remote) your develop branch to your fork
58+
9. [Send a pull request](https://help.github.com/en/articles/creating-a-pull-request)
59+
60+
The Maintainers 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.
61+
62+
Once the Maintainer handling your pull request is happy with it they will merge it into develop and your patch will be part of the next release.
63+
64+
### Setup
65+
1. You will need to install the Webby Framework through composer
66+
67+
```bash
68+
$ composer create-project sylynder/webby webby-setup
69+
```
70+
71+
2. You can now navigate to the vendor folder in your webby-setup project and inside the [sylynder] directory you need to delete the engine directory
72+
73+
3. When done you can clone your forked branch of the sylynder/engine repo
74+
from the lastest : [your-branch](https://github.com/<your-git-user>/engine)
75+
76+
NB: Please note that your forked branch should come from the main branch
77+
78+
4. You can now work on the your new changes in the cloned repo.
79+
80+
5. After you have tested all new features that you have added make a pull request to the [develop] branch
81+
82+
6. Your changes will be reviewed and merged as it passes all checks
83+
84+
### Branching (Making and Submitting Changes)
85+
86+
We follow [the successful Git branching model](http://nvie.com/posts/a-successful-git-branching-model/).
87+
88+
- Create a **topic/feature** branch from where you want to base your work. This is usually the **develop** branch: `$ git checkout -b mynewfeature develop`
89+
- For bug fixes, create a branch from main `$ git checkout -b mybugfix main`.
90+
- Better avoid working directly on the main branch, to avoid conflicts if you pull in updates from origin.
91+
- Make commits using descriptive commit messages and reference the #issue number (if any).
92+
- Push your changes to a topic branch in your fork of the repository.
93+
- Submit a pull request to [the sylynder/engine original repository](https://github.com/sylynder/engine), with the correct target branch.
94+
95+
## Which branch?
96+
97+
- Bugfix branches will be based on main.
98+
- New features will be based on the branch **develop** or the target release branch if any.
99+
100+
Looking at the nature of the Webby Framework, it has it's engine in a different Github repository [sylynder/engine](https://github.com/sylynder/engine)
101+
And so all contributions will have to be focused on that repository. It has been hard to figure out how to allow contributors to add to the project.
102+
103+
Currently Pull requests are to be sent to the develop branch of the Github repo [sylynder/engine](https://github.com/sylynder/engine)
104+
which will be coming from your forked branch at your end.
105+
106+
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.
107+
108+
### Signing
109+
110+
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 Webby fork.
111+
112+
`git commit --signoff`
113+
114+
or simply
115+
116+
`git commit -s`
117+
118+
This will sign your commits with the information setup in your git config, e.g.
119+
120+
`Signed-off-by: Oteng Kwame <[email protected]>`
121+
122+
123+
### Keeping your fork up-to-date
124+
To keep your fork up to date, you can visit your forked repo and go to the "Sync Fork" drop-down. You will see two buttons
125+
1. Compare
126+
2. Update Branch
127+
128+
Click on the "Update Branch" button to sync and update your fork to the current version.
129+
130+
### Notice
131+
Currently figuring things out on how to improve contributions. Stay Tuned

LICENSE renamed to LICENSE.md

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -9,13 +9,13 @@ to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
99
copies of the Software, and to permit persons to whom the Software is
1010
furnished to do so, subject to the following conditions:
1111

12-
The above copyright notice and this permission notice shall be included in all
13-
copies or substantial portions of the Software.
12+
The above copyright notice and this permission notice shall be included in
13+
all copies or substantial portions of the Software.
1414

1515
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
1616
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
1717
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
1818
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
1919
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20-
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21-
SOFTWARE.
20+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
21+
THE SOFTWARE.

‎SECURITY.md‎

Lines changed: 27 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,27 @@
1+
# Security Policy
2+
3+
The development team and community take all security issues seriously. **Please do not make public any uncovered flaws.**
4+
5+
## Reporting a Vulnerability
6+
7+
Thank you for improving the security of our code! Any assistance in removing security flaws will be acknowledged.
8+
9+
**Please report security flaws by emailing the development team directly: [email protected]**.
10+
11+
The lead maintainer will acknowledge your email within 48 hours, and will send a more detailed response within 48 hours indicating
12+
the next steps in handling your report. After the initial reply to your report, the security team will endeavor to keep you informed of the
13+
progress towards a fix and full announcement, and may ask for additional information or guidance.
14+
15+
## Disclosure Policy
16+
17+
When the security team receives a security bug report, they will assign it to a primary handler.
18+
This person will coordinate the fix and release process, involving the following steps:
19+
20+
- Confirm the problem and determine the affected versions.
21+
- Audit code to find any potential similar problems.
22+
- Prepare fixes for all releases still under maintenance. These fixes will be released as fast as possible.
23+
- Publish security advisories at https://github.com/sylynder/engine/security/advisories
24+
25+
## Comments on this Policy
26+
27+
If you have suggestions on how this process could be improved please submit a Pull Request.

0 commit comments

Comments
 (0)