diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..d5914e9 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,110 @@ +# Contributing + +Thank you for contributing to KGraphQL! +All contributions are welcome, feel free to open issues and PRs. + +## Getting Started + +To perform a local build you only need to have JDK 11 installed and invoke + +```bash +./gradlew build +``` + +You can verify your changes using + +```bash +./gradlew check +``` + +## Creating a Pull Request + +Pull requests are the best way of getting your changes into the code base. +Before opening a pull request for non-trivial changes, it might be good to open an issue for discussion first to +avoid unnecessary work, although this is not required. + +To support reviewing your changes please + +- Target the `main` branch +- Submit **one** pull request per bug or feature to keep the changes small and concise +- Follow existing code style and conventions +- Add automated tests when possible +- Structure your changes in as little _meaningful_ commits as possible. Don't be shy to force-push if needed. + +## Writing Commit Messages + +Commit messages matter. Please have a look at [How to Write a Git Commit Message](https://cbea.ms/git-commit/) for a +more thorough view. + +- Separate subject from body with a blank line +- Limit the subject line to 50 characters +- Capitalize the subject line +- Do not end the subject line with a period +- Use the imperative mood in the subject line ("Fix networking issue") +- Wrap the body at about 72 characters +- Use the body to explain **what** and **why**, not *how* (the code shows that) + +Example: + +```text +Summarize changes in around 50 characters or less + +More detailed explanatory text, if necessary. Wrap it to about 72 +characters or so. In some contexts, the first line is treated as the +subject of the commit and the rest of the text as the body. The +blank line separating the summary from the body is critical (unless +you omit the body entirely); various tools like `log`, `shortlog` +and `rebase` can get confused if you run the two together. + +Explain the problem that this commit is solving. Focus on why you +are making this change as opposed to how (the code explains that). +Are there side effects or other unintuitive consequences of this +change? Here's the place to explain them. + +Further paragraphs come after blank lines. + + - Bullet points are okay, too + + - Typically a hyphen or asterisk is used for the bullet, preceded + by a single space, with blank lines in between, but conventions + vary here + +If you use an issue tracker, put references to them at the bottom, +like this: + +Resolves: #123 +See also: #456, #789 +``` + +## Developer Certificate of Origin + +Lastly, the boring (but unfortunately important) legal part. Tl;dr: you guarantee that you did not simply copy&paste +someone else's code without permission. + +``` +Developer's Certificate of Origin 1.1 + +By making a contribution to this project, I certify that: + +(a) The contribution was created in whole or in part by me and I +have the right to submit it under the open source license +indicated in the file; or + +(b) The contribution is based upon previous work that, to the best +of my knowledge, is covered under an appropriate open source +license and I have the right under that license to submit that +work with modifications, whether created in whole or in part +by me, under the same open source license (unless I am +permitted to submit under a different license), as indicated +in the file; or + +(c) The contribution was provided directly to me by some other +person who certified (a), (b) or (c) and I have not modified +it. + +(d) I understand and agree that this project and the contribution +are public and that a record of the contribution (including all +personal information I submit with it, including my sign-off) is +maintained indefinitely and may be redistributed consistent with +this project or the open source license(s) involved. +``` diff --git a/README.MD b/README.MD index d36a916..69244ff 100644 --- a/README.MD +++ b/README.MD @@ -1,6 +1,7 @@ # KGraphQL [![Maven Central](https://img.shields.io/maven-central/v/de.stuebingerb/kgraphql.svg?label=Maven%20Central)](https://search.maven.org/search?q=g:%22de.stuebingerb%22%20AND%20a:%22kgraphql%22) +[![CodeQL](https://github.com/stuebingerb/KGraphQL/actions/workflows/github-code-scanning/codeql/badge.svg)](https://github.com/stuebingerb/KGraphQL/actions/workflows/github-code-scanning/codeql) KGraphQL is a [Kotlin](https://kotlinlang.org/) implementation of [GraphQL](http://graphql.org/) based on [aPureBase/KGraphQL](https://github.com/aPureBase/KGraphQL). It provides a rich DSL to set up the GraphQL schema. @@ -39,23 +40,9 @@ fun main() { See the [documentation](https://kgraphql.io/) for a more detailed explanation of the library. -## Contributing - -All contributions are welcome. Feel free to open issues and PRs! - -## Building - -To build KGraphQL you only need to have JDK 11 installed. Invoke - -```bash -./gradlew build -``` - -To perform local build. - ## Versioning -The versioning from 1.0.0 on is following [Semantic Versioning](http://semver.org/) +The versioning from 1.0.0 on follows [Semantic Versioning](http://semver.org/). ## Links @@ -63,4 +50,4 @@ Specification: https://spec.graphql.org/ ## License -KGraphQL is Open Source software released under the [MIT license](https://opensource.org/licenses/MIT) +KGraphQL is Open Source software released under the [MIT license](https://opensource.org/licenses/MIT). diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 0000000..058ec34 --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,16 @@ +# Security Policy + +## Supported Versions + +Prior to 1.0.0, security patches will be applied to the **current** version only. + +## Reporting a Vulnerability + +This repository supports [privately reporting a security vulnerability +](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability). + +If you believe that you have found a security vulnerability, please **do not** file a public issue or disclose it +otherwise. Instead, report it privately via the process described above. + +When you report a vulnerability, please include as many details as possible, ideally even a PoC for an exploit. This +will help to significantly speed up the fix and verify that it is indeed resolved.