Alright folks, real talk time. BYK has moved on from Sentry. He was the anchor of these forums and a huge contributor to the success of self-hosted Sentry over the last several years. BYK
Who am I? My name is Chad Whitacre. I joined Sentry a year ago as the second engineer on the Open Source Team with BYK. Unfortunately, I was recently promoted to Head of Open Source and asked to build out a proper Open Source Program Office (OSPO) … which means I have even less time to get down and dirty and help with troubleshooting self-hosted installation issues.
What I would luuuuv to see is whether we can build back some real community support for self-hosted Sentry. If you’re a self-hosted user and interested in taking a more active role in community support and maintenance, how can I help you?
Are these forums still the best venue? Internally we’ve been talking about migrating to GitHub Discussions. Would that be better?
Would some scheduled office hours or meetups be valuable?
Beyond support requests, how should we prioritize feature requests and bug reports in the issue tracker?
I know some of you have been more or less involved in the onpremise/self-hosted forums, Discord, and GitHub over time, and we’ve done a more or less adequate job of supporting you and recognizing your contributions. Can we try again to build some real open source community around self-hosted Sentry?
I’m actually inclined to deprecate the forums in favor of GitHub Issues. We have to have GitHub Issues, we’re not going to get rid of those, and they’re perfectly serviceable for async discussion on support requests and other questions (such as whether to deprecate the forums in favor of GitHub Issues ). There’d be no more double-posting in Issues and the forum.
I also just work a lot better in GitHub Issues personally.
I feel like GitHub Discussions would be a perfect place to have troubleshooting conversations especially because you are right there where you can immediately open an issue if it turns out there is some bug or something to improve and for GitHub contributers having the conversation that led to an issue right there also sounds useful.
Having the conversations and “work” in a single place sounds great to me
On prioritization… IMO This issue will keep many people out from using onpremise and participating in the community if not fixed by Jan 2022, because RDS is deprecating postgres v9
Thanks for weighing in. At this point I am planning to put a notice at the top of the On-Premise forum tomorrow indicating that we’re moving, and to follow through with the move next week.
Noticing basic questions like Upgrade sentry 9.1.1 to last version … not really suitable for GitHub Issues. Would StackOverflow be a good place for those? Anyone ever try using SO for Sentry?
This way an issue can easily be converted to a discussion (and the other way around) and discussion can have (accepted) answers like on SO so it might be a great place to have these questions without clogging up the actual issues and keep those for actual bug (that might be discovered from a discussion).
Discussions is a valid suggestion, to be sure, and I sorta asked for it with the SO parallel.
That said, I’m going to stick with the GitHub Issues plan for now. Even with the forum here we have still have basic questions showing up in GitHub Issues already—I don’t see that going away if we migrate the forum to Discussions.
The reality is that users don’t really care which type of content in which channel, people are going to ask for help on any and every channel they discover that is easy for them to post to. Rather than trying to force certain content into certain channels (and then having to transfer content from one to the other, which is kinda clunky), I would rather see if we can just manage all content in one channel (or a minimal number—we still have have Discord and of course Twitter). I think we can do this with labels in GitHub issues.
Another consideration is that we have automation internally to measure our response time to incoming GitHub Issues. We could extend that to Discussions, but folding into Issues is lower-hanging fruit for bringing these conversations into our visibility framework.