Skip to content

Commit 605c76c

Browse files
laura-rodriguezlaura-rodriguez
committed
Add CONTRIBUTING.md.
Add CODE_OF_CONDUCT.md. UPdate README.md to reference to the CONTRIBUTING guide.
1 parent 778a402 commit 605c76c

File tree

3 files changed

+171
-0
lines changed

3 files changed

+171
-0
lines changed

‎CODE_OF_CONDUCT.md

+48
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,48 @@
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, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, 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 team 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.
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+
For answers to common questions about this code of conduct, see https://www.contributor-covenant.org/faq
46+
47+
[homepage]: http://contributor-covenant.org
48+
[version]: http://contributor-covenant.org/version/1/4/

‎CONTRIBUTING.md

+119
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,119 @@
1+
Contributing to Okta Open Source Repos
2+
======================================
3+
4+
Sign the CLA
5+
------------
6+
7+
you _may_ need to [sign the CLA](https://developer.okta.com/cla/), read it before getting started. Common questions/answers are also listed on the CLA page.
8+
9+
Summary
10+
-------
11+
This document covers how to contribute to an Okta Open Source project. These instructions assume you have a GitHub.com account, so if you don't have one you will have to create one. Your proposed code changes will be published to your own fork of the Okta ASP.NET Core Samples and you will submit a Pull Request for your changes to be added.
12+
13+
_Lets get started!!!_
14+
15+
16+
Fork the code
17+
-------------
18+
19+
In your browser, navigate to: [https://github.com/okta/samples-aspnetcore](https://github.com/okta/samples-aspnetcore)
20+
21+
Fork the repository by clicking on the 'Fork' button on the top right hand side. The fork will happen and you will be taken to your own fork of the repository. Copy the Git repository URL by clicking on the clipboard next to the URL on the right hand side of the page under '**HTTPS** clone URL'. You will paste this URL when doing the following `git clone` command.
22+
23+
On your computer, follow these steps to setup a local repository for working on the Okta ASP.NET Core Samples:
24+
25+
``` bash
26+
$ git clone https://github.com/YOUR_ACCOUNT/samples-aspnetcore.git
27+
$ cd okta-aspnetcore
28+
$ git remote add upstream https://github.com/okta/samples-aspnetcore.git
29+
$ git checkout master
30+
$ git fetch upstream
31+
$ git rebase upstream/master
32+
```
33+
34+
35+
Making changes
36+
--------------
37+
38+
It is important that you create a new branch to make changes on and that you do not change the `master` branch (other than to rebase in changes from `upstream/master`). In this example I will assume you will be making your changes to a branch called `feature_x`. This `feature_x` branch will be created on your local repository and will be pushed to your forked repository on GitHub. Once this branch is on your fork you will create a Pull Request for the changes to be added to the Okta ASP.NET Core Samples.
39+
40+
It is best practice to create a new branch each time you want to contribute to the project and only track the changes for that pull request in this branch.
41+
42+
``` bash
43+
$ git checkout -b feature_x
44+
(make your changes)
45+
$ git status
46+
$ git add .
47+
$ git commit -a -m "descriptive commit message for your changes"
48+
```
49+
50+
> The `-b` specifies that you want to create a new branch called `feature_x`. You only specify `-b` the first time you checkout because you are creating a new branch. Once the `feature_x` branch exists, you can later switch to it with only `git checkout feature_x`.
51+
52+
53+
Rebase `feature_x` to include updates from `upstream/master`
54+
------------------------------------------------------------
55+
56+
It is important that you maintain an up-to-date `master` branch in your local repository. This is done by rebasing in the code changes from `upstream/master` (the official Okta ASP.NET Core Samples repository) into your local repository. You will want to do this before you start working on a feature as well as right before you submit your changes as a pull request. I recommend you do this process periodically while you work to make sure you are working off the most recent project code.
57+
58+
This process will do the following:
59+
60+
1. Checkout your local `master` branch
61+
2. Synchronize your local `master` branch with the `upstream/master` so you have all the latest changes from the project
62+
3. Rebase the latest project code into your `feature_x` branch so it is up-to-date with the upstream code
63+
64+
``` bash
65+
$ git checkout master
66+
$ git fetch upstream
67+
$ git rebase upstream/master
68+
$ git checkout feature_x
69+
$ git rebase master
70+
```
71+
72+
> Now your `feature_x` branch is up-to-date with all the code in `upstream/master`.
73+
74+
75+
Make a GitHub Pull Request to contribute your changes
76+
-----------------------------------------------------
77+
78+
When you are happy with your changes and you are ready to contribute them, you will create a Pull Request on GitHub to do so. This is done by pushing your local changes to your forked repository (default remote name is `origin`) and then initiating a pull request on GitHub.
79+
80+
> **IMPORTANT:** Make sure you have rebased your `feature_x` branch to include the latest code from `upstream/master` _before_ you do this.
81+
82+
``` bash
83+
$ git push origin master
84+
$ git push origin feature_x
85+
```
86+
87+
Now that the `feature_x` branch has been pushed to your GitHub repository, you can initiate the pull request.
88+
89+
To initiate the pull request, do the following:
90+
91+
1. In your browser, navigate to your forked repository: [https://github.com/YOUR_ACCOUNT/samples-aspnetcore](https://github.com/YOUR_ACCOUNT/samples-aspnetcore)
92+
2. Click the new button called '**Compare & pull request**' that showed up just above the main area in your forked repository
93+
3. Validate the pull request will be into the upstream `master` and will be from your `feature_x` branch
94+
4. Enter a detailed description of the work you have done and then click '**Send pull request**'
95+
96+
If you are requested to make modifications to your proposed changes, make the changes locally on your `feature_x` branch, re-push the `feature_x` branch to your fork. The existing pull request should automatically pick up the change and update accordingly.
97+
98+
> **Note**: Although we are using continuous integration, not all the tests will run from third party contributors. It is the repository owner’s responsibility to make sure that your changes don’t break anything before merging into master.
99+
100+
Cleaning up after a successful pull request
101+
-------------------------------------------
102+
103+
Once the `feature_x` branch has been committed into the `upstream/master` branch, your local `feature_x` branch and the `origin/feature_x` branch are no longer needed. If you want to make additional changes, restart the process with a new branch.
104+
105+
> **IMPORTANT:** Make sure that your changes are in `upstream/master` before you delete your `feature_x` and `origin/feature_x` branches!
106+
107+
You can delete these deprecated branches with the following:
108+
109+
``` bash
110+
$ git checkout master
111+
$ git branch -D feature_x
112+
$ git push origin :feature_x
113+
```
114+
115+
Code of Conduct
116+
---------------
117+
118+
This project and everyone participating in it is governed by the [Okta Code of Conduct](https://github.com/okta/samples-aspnetcore/tree/master/CODE_OF_CONDUCT.md). By participating, you are expected to uphold this code. Please report unacceptable behavior to [email protected].
119+

‎README.md

+4
Original file line numberDiff line numberDiff line change
@@ -9,3 +9,7 @@ Please find the sample that fits your use-case from the table below.
99
| [Okta-Hosted Login](/okta-hosted-login) | An application server that uses the hosted login page on your Okta org, then creates a cookie session for the user in the ASP.NET Core application. | Traditional web applications with server-side rendered pages. |
1010
| [Resource Server](/resource-server) | This is a sample API resource server that shows you how to authenticate requests with access tokens that have been issued by Okta. | Single-Page applications. |
1111
| [Self-Hosted Login](/self-hosted-login) | An application server that uses a self-hosted login page on your ASP.NET Core application. | Traditional web applications with server-side rendered pages. |
12+
13+
## Contributing
14+
15+
We're happy to accept contributions and PRs! Please see the [contribution guide](CONTRIBUTING.md) to understand how to structure a contribution.

0 commit comments

Comments
 (0)