You mean that a company that employs 10 devs for 60k (way below real salary of US companies - that the pledge is focused at the moment) which is 600k is not able to pay additional 20k to various maintainers, that will not even get entire 20k just just a small percentage?
Noone is against OpenAPI, definitely on the author, thing is that OpenAPI is just not for everything and AsyncAPI complements the rest. AsyncAPI doesn't have to imagine anything, ecosystem is already there :) MQTT,Kafka, Websocket and others were there long time before AsyncAPI. I recommend you look at the article once again.
very depends on your use case and what you want to achieve in the end. Code gen? types gen or entire app? docs only? discovery? It always all depends :)
Can you share how many spam PRs did you have? I thought to check here https://github.com/chartjs/Chart.js/pulls on my own but unfortunately you did not mark those with invalid or spam labels. For such a popular project like yours, did you get many? Was it overwhelming?
we should also take into account that world is huge and English is used by many people around the world, non-native like me and they make mistakes not because they want to do it but because they just happen. And yeah, I wrote the title with a spelling mistake, without checking it as I was sure it is written properly and my Grammarly plugin doesn't support checking the title of the submission.
So don't overcomplicate things :) and sorry for the mistake, I'll do better next time.
Guy from GitHub suggested the same, but how would you really see such workflow in action? all I have in mind seems so complicated that easier would be to write and host dedicated bot really. Supporting PR on Issue level sounds strange
I was wondering how do you use semantic-release tooling in non-js. Do you use ".releaserc" file for config and then on CI execute with npx, to have pure repo with no JS thingy? Or are you just using package.json normally? maybe hidden in ".github" ?
I wanted to also introduce PR title validation, so there is no mistake possible on merging and we follow convetional commits 100% but unfortunately GitHub Actions do not support fork-based workflow properly and those PR checks would be useless :(
You install first in your Kubernetes cluster a project build by one of the k8s SIGs called Service Catalog that is capable to connect multiple different brokers into one service offering.
And you can start consuming and manage services exposed through the helm broker, so all the different helm charts that you've bundled into a special package that is compatible with OSBAPI. Here is an example of such packaged helm chart that later on is visible in the catalog https://github.com/kyma-project/addons/tree/master/addons/re...