On Mon, Oct 31, 2022 at 3:44 PM Neal Gompa ngompa13@gmail.com wrote:
On Mon, Oct 31, 2022 at 3:40 PM Josh Boyer jwboyer@redhat.com wrote:
On Mon, Oct 31, 2022 at 3:30 PM Neal Gompa ngompa13@gmail.com wrote:
On Mon, Oct 31, 2022 at 3:09 PM Josh Boyer jwboyer@redhat.com wrote:
On Mon, Oct 31, 2022 at 3:06 PM Neal Gompa ngompa13@gmail.com wrote:
On Mon, Oct 31, 2022 at 2:57 PM Shaun McCance shaunm@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 a bit of a catch-22 there I think, I'm not sure how to resolve that...
I'm not sure there's anything to resolve. IRC being vibrant isn't really a metric I'd consider critical to the project. Engagement in some form probably is, but it should be looked at in aggregate, not on a specific platform/channel basis.
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.
It's the former rather than the latter. I would also say that having dead silence for months is not appropriate no matter what kind of misconstrued conflations people might think of.
I agree. To be clear, we're working on that for RHEL as a whole, not just CentOS Stream MRs. It is not uncommon for some bugs to be open for years in RHEL, much to my disliking.
josh