Feedback wanted re Github Discussions

[cczona]

In recent weeks we've been exploring use of GitHub Discussions. Its biggest advantages include persistence (Slack messages disappear after 3 months), search engine indexing (the world doesn't get to see how welcoming and responsive our Slack community is!), and excellent integration with GH Issues. Now that folks have had a chance to give it a try, thoughts please! Shall we expand the experiment a bit by increasing the number of conversations we hold on Discussions?

[sureshjoshi]

Under the assumption that discussions are not intended for traditional support or bugs, but moreso about design decisions, API changes, etc - I think it's working relatively well.

There are still large Google design documents - which are nice for more seamless commenting, but those would be the primary "thing" to move over to discussions I think.

[cczona]

+1 re big picture development decisions. I appreciate how it enhances institutional memory and makes it easier for newcomers to pick up on where opportunity lies to make valuable contributions.

We're also exploring potential for using Discussions for traditional support; while likely leaving Slack in place for the sake of informal chat, private channels, and DMing. Github Discussions doesn't support the latter two, and both will remain needed. Still it'd be best to designate one space as the primary locus of tech support, so end users have a consistent place to get their needs met without being bounced around. So if we were to ultimately* commit to Discussions long-term, it would need to support tech support goals while adding its benefits of persistence, public access/indexing, etc. What are your impressions so far of doing tech support via Discussions? As we experiment with expanding the number of sample support discussions here, what criteria are important to you?

• No timeline has been set for reaching a decision, so exploration is still wide open.

For me the big criteria are that Pants' community's renowned responsiveness and welcoming culture need to be maintained. The limitations of the Discussions API for notifications is unfortunate. But is it a dealbreaker or just a minor inconvenience? The welcome channel here needs coaxing to life. But we accomplished that successfuly last year on Slack, and we can do it here too. So I don't consider that a problem now, especially since that challenge will get smaller as Discussions usage grows more lively.

[kaos]

For me it's been more difficult to track at a fine level of detail what is going on in GH discussions, but that may also be due to me not being familiar enough yet with how to approach it effectively. But that takes away a bit of the responsiveness, I think. As such, I think it is a little early for me to draw any conclusions just yet ;)

[cczona]

I agree. I think we'd need to either adapt to GH's style of notifications, or setup an alternative. Re the former, I notice that GH notifications can have custom filters. So hitting Save on https://github.com/notifications?query=is%3Adiscussion+is%3Aunread at least gives an easy quickview of new discussions that one hasn't read yet. However that's a different model than what we're used to. Re alternatives, perhaps Zapier etc has something useful. But it'd be using the Github Notifications API too, which seems to have a model of one notification total per thread rather than Slack's model of notifying that the thread has additional comments.