-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Co-authored-by: Jorge Brisa <jorge.br.ib@gmail.com>
- Loading branch information
Showing
4 changed files
with
335 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,75 @@ | ||
|
||
# Contributor Covenant Code of Conduct | ||
|
||
## Our Pledge | ||
|
||
In the interest of fostering an open and welcoming environment, we as | ||
contributors and maintainers pledge to make participation in our project and | ||
our community a harassment-free experience for everyone, regardless of age, body | ||
size, disability, ethnicity, sex characteristics, gender identity and expression, | ||
level of experience, education, socio-economic status, nationality, personal | ||
appearance, race, religion, or sexual identity and orientation. | ||
|
||
## Our Standards | ||
|
||
Examples of behavior that contributes to creating a positive environment | ||
include: | ||
|
||
* Using welcoming and inclusive language | ||
* Being respectful of differing viewpoints and experiences | ||
* Gracefully accepting constructive criticism | ||
* Focusing on what is best for the community | ||
* Showing empathy towards other community members | ||
|
||
Examples of unacceptable behavior by participants include: | ||
|
||
* The use of sexualized language or imagery and unwelcome sexual attention or | ||
advances | ||
* Trolling, insulting/derogatory comments, and personal or political attacks | ||
* Public or private harassment | ||
* Publishing others' private information, such as a physical or electronic | ||
address, without explicit permission | ||
* Other conduct which could reasonably be considered inappropriate in a | ||
professional setting | ||
|
||
## Our Responsibilities | ||
|
||
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. | ||
|
||
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. | ||
|
||
## Scope | ||
|
||
This Code of Conduct applies within all project spaces, and it also applies when | ||
an individual is representing the project or its community in public spaces. | ||
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. | ||
|
||
## Enforcement | ||
|
||
Instances of abusive, harassing, or otherwise unacceptable behavior may be | ||
reported by contacting the project team at [conduct@golossus.com][1]. | ||
All complaints will be reviewed and investigated and will result in a response that | ||
is deemed necessary and appropriate to the circumstances. The project team is | ||
obligated to maintain confidentiality with regard to the reporter of an incident. | ||
Further details of specific enforcement policies may be posted separately. | ||
|
||
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. | ||
|
||
## Attribution | ||
|
||
This Code of Conduct is adapted from the [Contributor Covenant][2], version 1.4, | ||
available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html | ||
|
||
[1]: mailto:conduct@golossus.com | ||
[2]: https://www.contributor-covenant.org |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,231 @@ | ||
Contributing | ||
------------ | ||
This PHP library is an open source, community-driven project. Even though Golossus was started to focus on Go language modules, | ||
the mantainers decided to also share other projects written in other languages under the umbrella of the Golossus organization. | ||
|
||
If you'd like to contribute, please read the following sections. | ||
|
||
Submitting a patch | ||
------------------ | ||
A pull request is the best way to propose changes. Follow next steps to propose yours. | ||
|
||
### Step 1: Check existing Issues and Pull Requests | ||
Before start any work, check to see if someone else also stated the same problem or even started working on a pull | ||
request by searching on [GitHub][1]. | ||
|
||
If you are unsure or have any questions, please ask your questions on the #contribs channel on [Golossus Slack][2]. | ||
|
||
### Step 2: Setup your Environment | ||
You will need to have **Git** installed and an account on Github. Set up your user information to match your Github account | ||
details, but use your real name: | ||
|
||
```bash | ||
git config [--global or --local] user.name "Your Name" | ||
git config [--global or --local] user.email your.github@email.com | ||
``` | ||
|
||
Fork this [repository][1] to your Github account and ensure current tests pass before working on your Pull Request. | ||
|
||
### Step 3: Work on your Pull Request | ||
Before you start, you should be aware that all the code you are going to submit must be released under the [MIT license][3]. | ||
|
||
Work on current stable branch for fixes, and on main for new features. [Golossus team][4] will decide if some changes must | ||
be propagated to any other branches. | ||
|
||
You must create a Topic Branch from the previous ones, and provide a descriptive name including the ticket number if an | ||
issue for the code you're about to write exists. | ||
|
||
Work on the code as much as you want and commit as much as you want, but keep in mind to follow the rules on this document. | ||
|
||
Add unit tests to prove that the bug is fixed or that the new feature actually works. | ||
|
||
Try hard to not break backward compatibility, if you must do so, take into account that Pull Requests that break backward | ||
compatibility have less chance to be merged. | ||
|
||
Do atomic and logically separate commits (use the power of git rebase to have a clean and logical history). | ||
|
||
Never fix coding standards in some existing code as it makes the code review more difficult. | ||
|
||
Write good commit messages. | ||
|
||
### Step 4:Prepare your Pull Request for Submission | ||
When your Pull Request is not about a bug fix (when you add a new feature or change an existing one for instance), it | ||
must also include the following: | ||
|
||
* An explanation of the changes in the relevant CHANGELOG file(s), use the [BC BREAK] or the [DEPRECATION] prefix when relevant). | ||
* An explanation on how to upgrade an existing application in the relevant UPGRADE file(s) if the changes break backward | ||
compatibility or if you deprecate something that will ultimately break backward compatibility. | ||
* Add your name into the CONTRIBUTORS file if you're not yet added. | ||
|
||
### Step 5: Submit your Pull Request | ||
Whenever you feel that your Pull Request is ready for submission, follow the following steps. | ||
|
||
* Rebase your Pull Request, Before submitting it. | ||
* Fix merge conflicts if they appear during rebase. | ||
* Check that all tests still pass and push your branch remotely. | ||
* Finally make a pull request on the php-test-fixture-loading GitHub repository. | ||
|
||
### Step 6: Receiving Feedback | ||
We ask all contributors to follow a constructive feedback process. | ||
|
||
If you think someone fails to keep this advice in mind and you want another perspective, please join the #contribs | ||
channel on [Golossus Slack][2]. If you receive feedback you find abusive please contact the [conduct][5]. | ||
|
||
The Golossus team is responsible for deciding which code gets merged, so their feedback is the most relevant. | ||
So do not feel pressured to refactor your code immediately when someone provides feedback. | ||
|
||
Based on the feedback on the pull request, you might need to rework your Pull Request. As in step 5, you will need to | ||
rebase again and ensure tests are passing. | ||
|
||
Golossus team will ask you to "squash" your commits before merging it. This means you will convert many commits to one commit. | ||
|
||
Reporting a bug | ||
--------------- | ||
|
||
If you find a bug, please report it and help us make a better library. | ||
|
||
> CAUTION | ||
> | ||
> If you think you've found a security issue, please use the special [procedure][6] instead. | ||
Before submitting a bug: | ||
|
||
* Double-check the official documentation to see if it is just a misusing topic. | ||
* Ask for assistance on Stack Overflow and/or on the #support channel of the [Golossus Slack][2]. | ||
* If your problem definitely looks like a bug, report it using the official bug tracker of the corresponding package on | ||
Github. | ||
|
||
Basic rules to follow: | ||
|
||
* Use the title field to clearly describe the issue. | ||
* Describe the steps needed to reproduce the bug with short code examples. It's better to provide a test. | ||
* Give as much detail as possible about your environment (OS, PHP version, dependencies version, ...). | ||
* Any log, output or trace you provide must be done in plain text. Do not provide it as a screenshot, and be careful with | ||
sensitive information you might be sharing by mistake. | ||
* Optionally attach a patch. | ||
|
||
Reporting a security issue | ||
-------------------------- | ||
|
||
If you think that you have found a security issue, don't use the bug tracker and don't make it public. Instead, all | ||
security issues must be sent to [security@golossus.com][7]. Emails sent to this address are forwarded to the Golossus team. | ||
|
||
### Resolution process | ||
> While the Golossus team is working on a patch, please do not reveal the issue publicly. We will resolve the problem as | ||
> fast as possible depending on its severity. | ||
For each report, we first try to confirm the vulnerability. When it is confirmed, the Golossus team will work on a solution | ||
and they will follow the next series of steps: | ||
|
||
1. Notify the reporter to acknowledge the vulnerability. | ||
2. Work hard on a patch. | ||
3. Get a CVE identifier from [mitre.org][8]. | ||
4. Write a security post announcing the vulnerability for the [Golossus blog][9]. | ||
5. Send the patch and the contents of the announcement to the reporter for review. | ||
6. Apply the patch and package a new version. | ||
7. Publish the post and add an entrance to the [security advisories list][10] | ||
|
||
### Dependant Open-Source projects collaboration | ||
If you are using this package for your own open-source or project, let us know by sending an email to [downstream@golossus.com][13]. | ||
Include information about your project and/or company, and the package your are using. After verification of | ||
the information provided your company and/or project will be added into our security notification mailing list. Do not | ||
forget to include at least one email address where you want to receive security notifications. | ||
|
||
After notifying a security issue to the dependant projects, we will try to approach the right people of the project to set | ||
a strategy to help to update and adopt the fixes. | ||
|
||
> By sending the security issue notification request email, and after its approval, you allow us to contact by means of | ||
> the email(s) address(es) provided, not only to get notified about a security issue but also to ask for permission to | ||
> publish your project/company as a downstream project. | ||
#### Projects using it | ||
|
||
Currently there's no notified project using actively this package, we expect this to change in the future. | ||
|
||
### Severity scoring | ||
|
||
In order to determine the severity of a security issue we take into account: | ||
* The complexity of any potential attack. | ||
* The impact of the vulnerability. | ||
* The number of projects that may be affected. | ||
|
||
The Golossus team has not set yet a quantitative mechanism to score the severity of an issue, but taking into account the | ||
points mentioned before, we will categorize an issue into a level of: Low, Medium, High, or Critical. | ||
|
||
### Security advisories | ||
|
||
Check the Security Advisories blog category for a [list of all security vulnerabilities][10] | ||
that were fixed in previous releases. | ||
|
||
Golossus team | ||
------------- | ||
|
||
The Golossus team is the group of developers that drives and decides the direction and evolution of the Golossus project, | ||
and all its related packages. | ||
They have the power to reject, accept and merge the features and patches proposed by the community. | ||
|
||
This section states the rules Golossus members must adhere and follow. These rules are effective upon publication of this | ||
document. | ||
|
||
### Leaders | ||
* Santiago Garcia (sangarbe) | ||
* Jorge Brisa (jorbriib) | ||
|
||
### Membership application | ||
All the Golossus team members should be long-time contributors with demonstrated knowledge and commitment to push the | ||
project forward. Member applications must be sent to [members@golossus.com][11]. After evaluation | ||
by the team leaders, needed privileges will be granted to any accepted applications' sender. | ||
|
||
### Membership revocation | ||
Any member of the Golossus team may loose their membership if one of the following circumstances apply: | ||
* Not following the rules, conventions or code of conduct. | ||
* Long-time inactivity. | ||
* Demonstrated negligence or intention to harm the project. | ||
* Leader(s) decision. | ||
|
||
Development rules | ||
----------------- | ||
|
||
Golossus' projects development are based on pull requests proposed by any member of the community. However, this project | ||
is young and pull request acceptance or rejection is decided based on the criteria of Golossus team members. | ||
|
||
### Coding standards and conventions | ||
|
||
This project provides a [Php-cs-fixer configuration file][12] which provides the corresponding rules for coding formatting | ||
applied to this project. Any contributor must make use of this configuration. | ||
|
||
### Merging process | ||
All code must be committed to the repository through pull requests. After enough time for reviews by the team members, a | ||
pull request can be merged in the following cases: | ||
* Community pull request: Every team leader must accept the code. | ||
* Team member pull request: Only one team leader must accept the code. | ||
* Team leader pull request: A different team leader must accept the code. | ||
|
||
Only the team leaders can eventually merge a pull request. | ||
|
||
Even if team members (except team leaders) have not enough privileges to merge a pull request, they are allowed to ask | ||
for code completeness, refinement or changes in community pull request. Their help and effort is highly valuable to | ||
accelerate the lead time to accept and/or reject a pull request. | ||
|
||
Regardless team members approval/rejection, team leaders may change the final decision. | ||
|
||
### Release policy | ||
Team leaders are in charge of releasing every package version. | ||
|
||
Amendments | ||
---------- | ||
The rules described in this document may change at anytime at the discretion of the project leaders. | ||
|
||
[1]: https://github.com/golossus/php-test-fixture-loading | ||
[2]: https://join.slack.com/t/golossus/shared_invite/zt-db4brnes-M8q1Lw2ouFT5X~gQg69NQQ | ||
[3]: ./LICENSE | ||
[4]: #golossus-team | ||
[5]: mailto:conduct@golossus.com | ||
[6]: #reporting-a-security-issue | ||
[7]: mailto:security@golossus.com | ||
[8]: https://cve.mitre.org/cve/request_id.html | ||
[9]: http://www.golossus.com/blog | ||
[10]: http://www.golossus.com/security-advisories | ||
[11]: mailto:members@golossus.com | ||
[12]: ./.php_cs.dist | ||
[13]: mailto:downstream@golossus.com |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,8 @@ | ||
Contributors | ||
------------ | ||
|
||
The Golossus maintainers as coming from a PHP stack, decided to share this small library to the community. We hope the | ||
effort of many more contributors could be reflected onto this list: | ||
|
||
* Santiago Garcia Belmonte (sangarbe) | ||
* Jorge Brisa Ibañez (jorbriib) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,21 @@ | ||
MIT License | ||
|
||
Copyright (c) 2021 Santiago Garcia, Jorge Brisa | ||
|
||
Permission is hereby granted, free of charge, to any person obtaining a copy | ||
of this software and associated documentation files (the "Software"), to deal | ||
in the Software without restriction, including without limitation the rights | ||
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell | ||
copies of the Software, and to permit persons to whom the Software is | ||
furnished to do so, subject to the following conditions: | ||
|
||
The above copyright notice and this permission notice shall be included in all | ||
copies or substantial portions of the Software. | ||
|
||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR | ||
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, | ||
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE | ||
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER | ||
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, | ||
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE | ||
SOFTWARE. |