Sergio Moya

> The $ref from reply to operation would work for generation, but I see a drawback in use case here, because now pingReply has defined action = receive. Thus it...

> As soon as you have to operations it is not a classic request reply pattern. That's actually a good point @GreenRover.

In order to not pollute this issue about the topic "Should reply object become an operation object?", I created https://github.com/asyncapi/spec/issues/1009

> I suggest to provide definition of `reply` in the [Definitions](https://github.com/asyncapi/spec/blob/next-major-spec/spec/asyncapi.md#definitions) section, maybe as subpart of Message definition. Wondering if it is not already covered by the description of what...

First, i want to say thanks @derberg for catching this 🙌🙌. > Now, it is not something that I see in a production use cases I'm completely not sure about...

> It's low impact because it's on 2.6.0. I mean, it's not that some people can't continue using AsyncAPI, it's just that they won't be able to adopt 3.0.0, which...

We should include the examples embeded into the spec itself, not only the files under the examples dir. Related to this: https://github.com/asyncapi/spec/pull/971 In order to do that, those examples would...

I consider this as a potential issue for next Bounty program. Not sure if there is a way of keeping track potential issues for next rounds somewhere. Perhaps labels 🤔...

The work could be split in two phases: 1. Validation of all AsyncAPI documents under /examples dir in the Spec repo. https://github.com/asyncapi/spec/tree/master/examples. I believe we could use For the record,...

Considering @Shurtu-gal is already assigned to two Bounty issues already (having [reached the limit](https://github.com/asyncapi/community/pull/897/files#diff-25ecb20a61754c225d6511ca08d7e7c9a14b9ca5a93e89bd42331e51c9ebf26dR173)), it is automatically discarded from this one in favour of @AnimeshKumar923, who additionally applied earlier, and...