= Contributing to Spring Authorization Server

Spring Authorization Server is released under the Apache 2.0 license.
If you would like to contribute something, or simply want to hack on the code this document should help you get started.

== Feature Planning
This project uses https://www.zenhub.com/[ZenHub] to prioritize the feature roadmap and help organize the project plan.
The project board can be accessed https://app.zenhub.com/workspaces/authorization-server-5e8f3182b5e8f5841bfc4902/board?repos=248032165[here].
It is recommended to install the ZenHub https://www.zenhub.com/extension[browser extension] as it integrates natively within GitHub's user interface.

== Code of Conduct
This project adheres to the Contributor Covenant link:CODE_OF_CONDUCT.adoc[code of conduct].
By participating, you are expected to uphold this code.
Please report unacceptable behavior to spring-code-of-conduct@pivotal.io.

== Using GitHub Issues
We use GitHub issues to track bugs and enhancements.
If you have a general usage question please ask on https://stackoverflow.com[Stack Overflow].
The Spring Security team and the broader community monitor the https://stackoverflow.com/tags/spring-security[`spring-security`] tag.

If you are reporting a bug, please help to speed up problem diagnosis by providing as much information as possible.
Ideally, that would include a https://stackoverflow.com/help/minimal-reproducible-example[complete & minimal sample project] that reproduces the problem.

== Submitting Pull Requests
This project uses https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests[pull requests] for the community to suggest changes to the project.
There are a few imporant things to keep in mind when submitting a pull request:

* Expect feedback and to make changes to your contributions.
* Unless it is a minor change:
** It is best to discuss pull requests on an issue before doing work
** We expect the pull request to start with a https://github.blog/2019-02-14-introducing-draft-pull-requests/[draft pull request].
*** The pull request should be as small as possible and focus on a single unit of change.
This ensures that we are collaborating together as soon as possible.
*** Generally, this means do not introduce any new interfaces and as few classes as possible.
That may mean using an external library directly in a `Filter`.
*** We will discuss with you how to iterate once you have submitted the initial draft pull request.

== Reporting Security Vulnerabilities
If you think you have found a security vulnerability please *DO NOT* disclose it publicly until we've had a chance to fix it.
Please don't report security vulnerabilities using GitHub issues, instead head over to https://pivotal.io/security and learn how to disclose them responsibly.

== Sign the Contributor License Agreement
Before we accept a non-trivial patch or pull request we will need you to https://cla.pivotal.io/sign/spring[sign the Contributor License Agreement].
Signing the contributor's agreement does not grant anyone commit rights to the main repository, but it does mean that we can accept your contributions, and you will get an author credit if we do.
Active contributors might be asked to join the core team, and given the ability to merge pull requests.

== Apache License header

Please add the Apache License header to all new classes, for example:

```java
/*
 * Copyright 2020 the original author or authors.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      https://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */
```

== Squash commits

Use git rebase –interactive, git add –patch and other tools to "squash" multiple commits into atomic changes.

== Format commit messages

. Keep the subject line to 50 characters or less if possible.
. Do not end the subject line with a period.
. In the body of the commit message, explain how things worked before this commit, what has changed, and how things work now.
. Include Fixes gh-<issue-number> at the end if this fixes a GitHub issue.
. Avoid markdown, including back-ticks identifying code.
