On Mon, Oct 31, 2022 at 3:30 PM Neal Gompa <ngompa13 at gmail.com> wrote: > > On Mon, Oct 31, 2022 at 3:09 PM Josh Boyer <jwboyer at redhat.com> wrote: > > > > On Mon, Oct 31, 2022 at 3:06 PM Neal Gompa <ngompa13 at gmail.com> wrote: > > > > > > On Mon, Oct 31, 2022 at 2:57 PM Shaun McCance <shaunm at redhat.com> wrote: > > > > > > > > Hi all, > > > > > > > > You might be aware that there is a CentOS category on the Fedora > > > > Discourse instance: > > > > > > > > https://discussion.fedoraproject.org/c/centos/71 > > > > > > > > There have been some discussions about having a dedicated Discourse > > > > instance for CentOS. Discourse has a lot of advantages, such as better > > > > moderation and integration with our accounts system. But I understand > > > > that many people are comfortable with their existing workflows. > > > > > > > > There's no point in running Discourse if it doesn't get enough buy-in. > > > > So I'm asking for input on using Discourse for various things: > > > > > > > > * Project announcements, like events, meetings, and infra changes > > > > > > > > * Activity reports, such as for SIGs and events > > > > > > > > * User support, replacing forums.centos.org > > > > > > > > * Development of Stream itself, basically centos-devel > > > > > > > > * Development of stuff inside SIGs > > > > > > > > * Replacement for the comments section of the blog > > > > > > > > * Alternatively, just replacing the blog entirely > > > > > > > > * Something else I'm not thinking of > > > > > > > > > > From my point of view, I'd look at a CentOS Discourse as a replacement > > > for the older CentOS Forums. I would rather not replace the developer > > > discussions with Discourse, but user support and engagement places, > > > sure. > > > > > > Activity reports and such should be going out to the blog because > > > that's how the media is going to pick it up. Notably, the CentOS > > > Hyperscale SIG is continuously in the news because we did the > > > extremely simple thing of always having our reports on the blog. SIGs > > > that don't do that don't get talked about. They don't get mindshare, > > > and they don't get growth and further interest. > > > > I do like the blog posts. Those from Hyperscaler are quite nice. > > > > > I prefer the mailing list for developer discussions because it allows > > > me to tag people into discussions easily enough. However, CentOS > > > Stream development is currently not in a very good place because > > > almost nobody from RHEL engineering is here. Same goes for the IRC > > > channels and any other medium. CentOS Stream development remains > > > horrifically opaque, and that is a bug. Unless things change at some > > > point, most mailing lists could be closed with not that much impact, > > > since there's no communication anyway. > > > > What kind of communication/interaction are you expecting? > > > > On the mailing list, it'd be nice to see RHEL developer folks > notifying folks of big changes landing (like what Alexander Bokovoy > and Florian Weimer do from time to time) so that the community can > give feedback and test. Also, having RHEL folks on the mailing list We've been trying to encourage more of that. I agree it's very beneficial, even if the people providing the posts get very little response. > would mean that we can make the happy path for contributors trying to > reach RHEL folks about contributions much simpler. On the IRC channel, > it'd just be good to see them hanging out so the discussions in there > could be more productive and useful. I try to pull in relevant people when a conversation comes up that I think they could contribute to. The issue as far as I can see is there's very little chatter in the IRC channels in general. > There's also the problem of not being able to figure out who is the > maintainer for a package to contact them when sending merge requests. > It seems GitLab emails go to /dev/null for a lot of them, which makes > things difficult overall. Why do you need to contact them outside of the MR itself? The maintainers should be watching their projects and getting notifications that way. Notably, there are several packages that have multiple maintainers and cascading a bunch of email addresses for people to email after an MR is filed isn't really something we're going for. If you need to contact them because they don't respond at all, then we're working on that. If it's "they don't merge my stuff fast enough or tell me what to do instead", then I would say we need to be careful we're not conflating contribution with priority. josh