Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: improving contributing guide #131

Merged
merged 14 commits into from
Apr 18, 2024
88 changes: 13 additions & 75 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -1,79 +1,17 @@
# Contributing to AsyncAPI
We love your input! We want to make contributing to this project as easy and transparent as possible.
# Contributing Extensions for AsyncAPI Specification

## Contribution recogniton
Extensions catalog is like a waiting room for main specification features. Goal for the extensions catalog is to enable easier and faster contribution process than you see in [AsyncAPI Specification](https://github.com/asyncapi/spec/blob/master/CONTRIBUTING.md).

We use [All Contributors](https://allcontributors.org/docs/en/specification) specification to handle recognitions. For more details read [this](https://github.com/asyncapi/community/blob/master/recognize-contributors.md) document.
When proposing or weighing-in on any issue or pull request, consider the [Code of Conduct](https://github.com/asyncapi/.github/blob/master/CODE_OF_CONDUCT.md)
to better understand expected and unacceptable behavior.

## Summary of the contribution flow
## Guiding Principles

The following is a summary of the ideal contribution flow. Please, note that Pull Requests can also be rejected by the maintainers when appropriate.

```
┌───────────────────────┐
│ │
│ Open an issue │
│ (a bug report or a │
│ feature request) │
│ │
└───────────────────────┘
┌───────────────────────┐
│ │
│ Open a Pull Request │
│ (only after issue │
│ is approved) │
│ │
└───────────────────────┘
┌───────────────────────┐
│ │
│ Your changes will │
│ be merged and │
│ published on the next │
│ release │
│ │
└───────────────────────┘
```

## Code of Conduct
AsyncAPI has adopted a Code of Conduct that we expect project participants to adhere to. Please [read the full text](./CODE_OF_CONDUCT.md) so that you can understand what sort of behaviour is expected.

## Our Development Process
We use Github to host code, to track issues and feature requests, as well as accept pull requests.

## Issues
[Open an issue](https://github.com/asyncapi/asyncapi/issues/new) **only** if you want to report a bug or a feature. Don't open issues for questions or support, instead join our [Slack workspace](https://www.asyncapi.com/slack-invite) and ask there. Don't forget to follow our [Slack Etiquette](https://github.com/asyncapi/community/blob/master/slack-etiquette.md) while interacting with community members! It's more likely you'll get help, and much faster!

## Bug Reports and Feature Requests

Please use our issues templates that provide you with hints on what information we need from you to help you out.

## Pull Requests

**Please, make sure you open an issue before starting with a Pull Request, unless it's a typo or a really obvious error.** Pull requests are the best way to propose changes to the specification. Get familiar with our document that explains [Git workflow](https://github.com/asyncapi/community/blob/master/git-workflow.md) used in our repositories.

## Conventional commits

Our repositories follow [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/#summary) specification. Releasing to GitHub and NPM is done with the support of [semantic-release](https://semantic-release.gitbook.io/semantic-release/).

Pull requests should have a title that follows the specification, otherwise, merging is blocked. If you are not familiar with the specification simply ask maintainers to modify. You can also use this cheatsheet if you want:

- `fix: ` prefix in the title indicates that PR is a bug fix and PATCH release must be triggered.
- `feat: ` prefix in the title indicates that PR is a feature and MINOR release must be triggered.
- `docs: ` prefix in the title indicates that PR is only related to the documentation and there is no need to trigger release.
- `chore: ` prefix in the title indicates that PR is only related to cleanup in the project and there is no need to trigger release.
- `test: ` prefix in the title indicates that PR is only related to tests and there is no need to trigger release.
- `refactor: ` prefix in the title indicates that PR is only related to refactoring and there is no need to trigger release.

What about MAJOR release? just add `!` to the prefix, like `fix!: ` or `refactor!: `

Prefix that follows specification is not enough though. Remember that the title must be clear and descriptive with usage of [imperative mood](https://chris.beams.io/posts/git-commit/#imperative).

Happy contributing :heart:

## License
When you submit changes, your submissions are understood to be under the same [Apache 2.0 License](https://github.com/asyncapi/asyncapi/blob/master/LICENSE) that covers the project. Feel free to [contact the maintainers](https://www.asyncapi.com/slack-invite) if that's a concern.

## References
This document was adapted from the open-source contribution guidelines for [Facebook's Draft](https://github.com/facebook/draft-js/blob/master/CONTRIBUTING.md).
- Make sure that extension is well documented with good examples,
- Explain the use case,
- Try to improve existing extensions, before you contribute a competing one,
- Start discussion with an issue. Don't start with pull request first.
- Every extension file needs to be located in [extensions folder](https://github.com/asyncapi/extensions-catalog/tree/master/extensions)
- Observe the proper file naming convention, which calls for the lowercase name of the extension first.
- Pull request with new or improved extension will be merged only if there is compliant implementation in the the [AsyncAPI JSON Schema](https://github.com/asyncapi/spec-json-schemas).
- You do not have to fulfil all the requirements upon pull request creation. First focus on documentation and a use case. Once maintainers of the catalog tell you that it is the right time to work on tooling implementation, then start doing it or fund volunteers that can help.
3 changes: 3 additions & 0 deletions extensions/x.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,9 @@ This document defines how to use `twitter` extension in AsyncAPI documents.
## Overview
This extension allows you to provide the Twitter username of the account representing the team/company of the API.

## Version
Current version is `0.1.0`.

## Extension Definition

### Type: String
Expand Down
Loading