Cleaning up Coming Soon placeholders

I’d like to get opinions from the community and maintainers @msfussell @amulyavarote here.

Right now we have have a coming soon in the table for quickstarts for every API in Dapr. I think now that we have critical mass with APIs, this looks silly to have these coming soons, and I propose we track work here vs have Coming Soon on the website/docs.

I also think given cost to write and maintain these, and really support well, I’m not sure we want a quickstart for every single API forever. It would help to know where this is most useful to the community.

More specifically:

• Configuration - I believe we SHOULD do this based on high relevance to most apps and users. It is also a good API for this format.
• Observability - i believe we SHOULD NOT do this. I could be convinced however to configure the observability component to work well for all other quickstarts, and have a step that guides users to look at the Zipkin dashboard.
• Actors - I’m on the fence but currently believe we SHOULD do this since we see interest in actors and it may be harder to get going in a practical use case.
• Distributed Lock - right now this feels very narrow and not widely applicable, so I think we SHOULD NOT do a quickstart until we hear more interest. Dapr Docs? certainly.

Thoughts?

[amulyavarote]

@paulyuk I also think the priority should be given to configuration API. We can take out Observability from the list as an example is already included in the tutorials section.

[msfussell]

Issue resolved