docs: improving contributing guide #131
Conversation
sambhavgupta0705
requested review from
fmvilas,
derberg and
asyncapi-bot-eve
as code owners
|
@derberg here I have one doubt that what word should I follow everywhere |
|
|
derberg
changed the title
CONTRIBUTING.md
Outdated
| AsyncAPI is an evolving language. This repository contains the Extensions as well as Pull Requests with suggested improvements and contributions. | ||
|
|
||
| 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. | ||
| Contributions that do not change the interpretation of the extensions but instead improve legibility, fix editorial errors, clear up ambiguity and improve examples are encouraged and are often merged by a extension Committer with little process. | ||
|
|
||
| ## Summary of the contribution flow | ||
| However, contributions that _do_ meaningfully change the interpretation of the extensions must follow an RFC (Request For Comments) process through a series of *stages* intended to improve *visibility*, allow for *discussion* to reach the best solution, and arrive at *consensus*. This process becomes even more important as AsyncAPI's community broadens. |
There was a problem hiding this comment.
We can simplify even more and copy less from the spec. So remove these 3 paragraphs and write something like
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).
There was a problem hiding this comment.
I didn't understand this clearly
There was a problem hiding this comment.
instead of
write something similar to what I suggested
CONTRIBUTING.md
Outdated
| The AsyncAPI spec, despite describing technical behavior, is intended to be | ||
| read by people. Use natural tone and include motivation and examples. | ||
|
|
||
|
|
There was a problem hiding this comment.
everything below this comment can be removed. When I see it in this PR I kinda remind myself with spec and it makes me feel we do not make anything easy and just as complicated as in spec.
so just add another paragraph in Guiding section:
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), [AsyncAPI JS Parser](https://www.github.com/asyncapi/parser-js) and the [AsyncAPI React component](https://github.com/asyncapi/asyncapi-react).
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.
later once we have that figured in ☝🏼 mentioned repos, we can extend guid with links to proper instructions on how to do it.
Co-authored-by: Lukasz Gornicki <[email protected]>
Co-authored-by: Lukasz Gornicki <[email protected]>
Co-authored-by: Lukasz Gornicki <[email protected]>
Co-authored-by: Lukasz Gornicki <[email protected]>
|
Kudos, SonarCloud Quality Gate passed!
|
Co-authored-by: Lukasz Gornicki <[email protected]>
|
|
|
/rtm |
as a part of the asyncapi mentorship program it is recommended to make changes in the contribution guide and make it easy to read and implement for the new contributors