This repository has been archived by the owner on Nov 30, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 18
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
a522586
commit 3a4426b
Showing
7 changed files
with
491 additions
and
6 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,88 @@ | ||
| # 1. Contributor Covenant Code of Conduct | ||
|
|
||
| <!-- TOC --> | ||
|
|
||
| - [1. Contributor Covenant Code of Conduct](#1-contributor-covenant-code-of-conduct) | ||
| - [1.1. Our Pledge](#11-our-pledge) | ||
| - [1.2. Our Standards](#12-our-standards) | ||
| - [1.3. Our Responsibilities](#13-our-responsibilities) | ||
| - [1.4. Scope](#14-scope) | ||
| - [1.5. Enforcement](#15-enforcement) | ||
| - [1.6. Attribution](#16-attribution) | ||
|
|
||
| <!-- /TOC --> | ||
|
|
||
| ## 1.1. Our Pledge | ||
|
|
||
| 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, sex characteristics, gender identity and expression, | ||
| level of experience, education, socio-economic status, nationality, personal | ||
| appearance, race, religion, or sexual identity and orientation. | ||
|
|
||
| ## 1.2. 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 | ||
|
|
||
| ## 1.3. 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. | ||
|
|
||
| ## 1.4. Scope | ||
|
|
||
| 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. | ||
|
|
||
| ## 1.5. Enforcement | ||
|
|
||
| Instances of abusive, harassing, or otherwise unacceptable behavior may be | ||
| reported by contacting the project author at [email protected]. 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. | ||
|
|
||
| ## 1.6. Attribution | ||
|
|
||
| This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, | ||
| available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html | ||
|
|
||
| [homepage]: https://www.contributor-covenant.org | ||
|
|
||
| For answers to common questions about this code of conduct, see | ||
| https://www.contributor-covenant.org/faq |
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,121 @@ | ||
| # 1. Contribution Guidelines | ||
|
|
||
| <!-- TOC --> | ||
|
|
||
| - [1. Contribution Guidelines](#1-contribution-guidelines) | ||
| - [1.1. Contribution types](#11-contribution-types) | ||
| - [1.1.1. Bug Reports](#111-bug-reports) | ||
| - [1.1.2. Bug Fix](#112-bug-fix) | ||
| - [1.1.3. New Features](#113-new-features) | ||
| - [1.1.4. Documentation & Miscellaneous](#114-documentation--miscellaneous) | ||
| - [1.2. How To Contribute](#12-how-to-contribute) | ||
| - [1.2.1. Requirements](#121-requirements) | ||
| - [1.3. Open an issue and fork the repository](#13-open-an-issue-and-fork-the-repository) | ||
| - [1.3.1. Performing changes](#131-performing-changes) | ||
| - [1.3.2. Open a pull request](#132-open-a-pull-request) | ||
|
|
||
| <!-- /TOC --> | ||
|
|
||
| > Note: If these contribution guidelines are not followed your issue or PR might be closed, so | ||
| > please read these instructions carefully. | ||
| ## 1.1. Contribution types | ||
|
|
||
| ### 1.1.1. Bug Reports | ||
|
|
||
| - If you find a bug, please first report it using [Github issues]. | ||
| - First check if there is not already an issue for it; duplicated issues will be closed. | ||
|
|
||
| ### 1.1.2. Bug Fix | ||
|
|
||
| - If you'd like to submit a fix for a bug, please read the [How To](#12-how-to-contribute) for how to | ||
| send a Pull Request. | ||
| - Indicate on the open issue that you are working on fixing the bug and the issue will be assigned | ||
| to you. | ||
| - Write `Fixes #xxxx` in your PR text, where xxxx is the issue number (if there is one). | ||
| - Include a test that isolates the bug and verifies that it was fixed. | ||
|
|
||
| ### 1.1.3. New Features | ||
|
|
||
| - If you'd like to add a feature to the library that doesn't already exist, feel free to describe | ||
| the feature in a new [GitHub issue]. | ||
| - If you'd like to implement the new feature, please wait for feedback from the project maintainers | ||
| before spending too much time writing the code. In some cases, enhancements may not align well | ||
| with the project objectives at the time. | ||
| - Implement the code for the new feature and please read the [How To](#12-how-to-contribute). | ||
|
|
||
| ### 1.1.4. Documentation & Miscellaneous | ||
|
|
||
| - If you have suggestions for improvements to the documentation, tutorial or examples (or something | ||
| else), we would love to hear about it. | ||
| - As always first file a [Github issue]. | ||
| - Implement the changes to the documentation, please read the [How To](#12-how-to-contribute). | ||
|
|
||
| ## 1.2. How To Contribute | ||
|
|
||
| ### 1.2.1. Requirements | ||
|
|
||
| For a contribution to be accepted: | ||
|
|
||
| - Documentation should always be updated or added.\* | ||
| - Examples should always be updated or added.\* | ||
| - Tests should always be updated or added.\* | ||
| - Start your PR title with a [conventional commit] type | ||
| (`feat:`, `fix:` etc). | ||
|
|
||
| \*When applicable. | ||
|
|
||
| If the contribution doesn't meet these criteria, a maintainer will discuss it with you on the issue | ||
| or PR. You can still continue to add more commits to the branch you have sent the Pull Request from | ||
| and it will be automatically reflected in the PR. | ||
|
|
||
| ## 1.3. Open an issue and fork the repository | ||
|
|
||
| - If it is a bigger change or a new feature, first of all | ||
| [file a bug or feature report][github issues], so that we can discuss what direction to follow. | ||
| - [Fork the project][fork guide] on GitHub. | ||
| - Clone the forked repository to your local development machine | ||
| (e.g. `git clone [email protected]:<YOUR_GITHUB_USER>/twitter-oauth2-pkce.git`). | ||
|
|
||
| ### 1.3.1. Performing changes | ||
|
|
||
| - Create a new local branch from `main` (e.g. `git checkout -b my-new-feature`) | ||
| - Make your changes. | ||
| - When committing your changes, make sure that each commit message is clear | ||
| (e.g. `git commit -m 'Take in an optional something as a parameter to twitter-oauth2-pkce'`). | ||
| - Push your new branch to your own fork into the same remote branch | ||
| (e.g. `git push origin my-username.my-new-feature`, replace `origin` if you use another remote.) | ||
|
|
||
| ### 1.3.2. Open a pull request | ||
|
|
||
| Go to the [pull request page of twitter_oauth2_pkce][prs] and in the top | ||
| of the page it will ask you if you want to open a pull request from your newly created branch. | ||
|
|
||
| The title of the pull request should start with a [conventional commit] type. | ||
|
|
||
| Examples of such types: | ||
|
|
||
| - `fix:` - patches a bug and is not a new feature. | ||
| - `feat:` - introduces a new feature. | ||
| - `docs:` - updates or adds documentation or examples. | ||
| - `test:` - updates or adds tests. | ||
| - `refactor:` - refactors code but doesn't introduce any changes or additions to the public API. | ||
|
|
||
| If you introduce a **breaking change** the conventional commit type MUST end with an exclamation | ||
| mark (e.g. `feat!: Remove the argument from ClassA`). | ||
|
|
||
| Examples of PR titles: | ||
|
|
||
| - feat: Added new `scope`s | ||
| - fix: Avoid execute something in `TwitterOAuth2` | ||
| - docs: Add a example | ||
| - docs: Improve the README | ||
| - test: Add test for `scope.dart` | ||
| - refactor: Optimize the structure of `TwitterOAuth2` | ||
|
|
||
| [github issue]: https://github.com/twitter-dart/twitter-oauth2-pkce/issues/new | ||
| [github issues]: https://github.com/twitter-dart/twitter-oauth2-pkce/issues/new | ||
| [prs]: https://github.com/twitter-dart/twitter-oauth2-pkce/pulls | ||
| [fork guide]: https://guides.github.com/activities/forking/#fork | ||
| [pubspec doc]: https://dart.dev/tools/pub/pubspec | ||
| [conventional commit]: https://www.conventionalcommits.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
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,46 @@ | ||
| # 1. Security Policies and Procedures | ||
|
|
||
| <!-- TOC --> | ||
|
|
||
| - [1. Security Policies and Procedures](#1-security-policies-and-procedures) | ||
| - [1.1. Reporting a Bug](#11-reporting-a-bug) | ||
| - [1.2. Disclosure Policy](#12-disclosure-policy) | ||
| - [1.3. Comments on this Policy](#13-comments-on-this-policy) | ||
|
|
||
| <!-- /TOC --> | ||
|
|
||
| This document outlines security procedures and general policies for the `twitter_oauth2_pkce` project created by `Kato Shinya`. | ||
|
|
||
| ## 1.1. Reporting a Bug | ||
|
|
||
| The team and community take all security bugs in `twitter_oauth2_pkce` seriously. | ||
| Thank you for improving the security of `twitter_oauth2_pkce`. We appreciate your efforts and | ||
| responsible disclosure and will make every effort to acknowledge your | ||
| contributions. | ||
|
|
||
| Report security bugs by emailing the lead maintainer at `[email protected]` or [here](https://github.com/twitter-dart/twitter-oauth2-pkce/issues). | ||
|
|
||
| The lead maintainer will acknowledge your email within 48 hours, and will send a | ||
| more detailed response within 48 hours indicating 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 progress towards a fix and full | ||
| announcement, and may ask for additional information or guidance. | ||
|
|
||
| Report security bugs in third-party modules to the person or team maintaining | ||
| the module. | ||
|
|
||
| ## 1.2. Disclosure Policy | ||
|
|
||
| When the security team receives a security bug report, they will assign it to a | ||
| primary handler. This person will coordinate the fix and release process, | ||
| involving the following steps: | ||
|
|
||
| - Confirm the problem and determine the affected versions. | ||
| - Audit code to find any potential similar problems. | ||
| - Prepare fixes for all releases still under maintenance. These fixes will be | ||
| released as fast as possible. | ||
|
|
||
| ## 1.3. Comments on this Policy | ||
|
|
||
| If you have suggestions on how this process could be improved please submit a | ||
| pull request. |
Oops, something went wrong.