Hi folks! I'm a Pinot user (not a developer) and have been amazed at the support I can get from the Pinot folks in this Slack workspace, they're awesome! I'd like to share some suggestions to other users though, to optimize things for them, but which also might help everyone else: 1. I noticed that usually to try to fix issues the #C011C9JHN7R channel is better, I noticed the Pinot devs more active there, so that's where I suggest users ask for help, not here; 2. One good practice I learned actually here in this workspace (can't remember with whom) whenever I have an issue, was to first start with a short question, and then in the thread for that same question, I put more lengthy information, like config files, stacktraces etc. This is super cool to avoid taking massive amounts of space of the channel wall - it reduces visual pollution, while maintaining the content for the people who want to get involved with that particular discussion.

Great input, @Diogo Baeder . Another recommendation I’ve got is that if you see someone ask a question via a GitHub issue, avoid answering it there. Instead, gently point them at this Slack workspace (and the appropriate channel), and ask them to close the issue.

Agreed. Using thread for discussion will also help make the thread to become a topic on https://www.linen.dev/s/apache-pinot/ and easier for searching

Slack is great for fast iteration on discussions etc. But GH issues are great for tracking. My recommendations would be to have GH issues for tracking, and once the discussions converge on slack, update GH issue with summary, to get best of both worlds.

@Mayank my recommendation about not using a GH issue to ask a question (instead of Slack) is that (a) typically these question don’t result in a PR, (b) each issue generates noise for everyone who watches GitHub activity, and (c) the resulting conversation isn’t as useful for others if it’s buried in a closed GH issue. Once a discussion has happened on Slack, if it would actually result in a PR then yes, an issue makes total sense. But in other OS projects I’m involved with, answering questions via GH issues can quickly become an inefficient use of committer time.

Good point

Yes, I completely agree on that @Ken Krugler. Typically, starting on slack to discuss and then deciding whether a problem is GH issue worthy works well.

Agreed