On 1/7/20 10:48 AM, Young, Gregory wrote: > My personal feeling is there have been very high barriers to contributing to CentOS. > > 1. Almost every bug report and fix needs to go to/come from RHEL and Fedora. Very few bug reports are fixed in CentOS then submitted upstream to RHEL and Fedora. > 2. The Contributing Documentation is sparse and very confusing. It needs to be re-written and updated, and the Wiki needs to either be upgraded to something more user friendly, or replaced with a proper knowledgebase application. We eagerly welcome people to contribute changes of any kind to the contributing documentation - the document itself - https://wiki.centos.org/Contribute - describes how to get edit rights to the Wiki. There is, indeed, a lot of confusing and/or outdated content in the wiki. We encourage folks to join the docs mailing list - https://lists.centos.org/mailman/listinfo/centos-docs - to discuss proposed changes/updates. If you haven't looked at the wiki in the past month, you may have missed that our awesome infra folks have, in fact, updated it. It's both more attractive, and *much* faster, than it was last year. > 3. Meetings need to be held in a more accessible location. Freenode IRC may have worked well in the past, but many companies are locking down their outbound rules and blocking services like IRC. I used to use a SSH tunnel to access Freenode, but even there, the "scheduled" meetings for the SIGs never seemed to happen. Even looking at the minutes from many, you see the host is the only person who joins. Let's migrate to a Slack/Discord server for meetings, and figure out a way to better publish the meetings. Even ignoring the innate controversy of the "what chat platform" discussion, there's the question of tooling. We currently have tools to capture meeting minutes for IRC, but not for other platforms. We recently moved meetings from #centos-devel to #centos-meeting to remove some of the noise factor on the main channel. But, as you note, the biggest concern, to me, is that these meetings don't even always happen, leaving uncertainty of what's going on, and how one can join the effort. This is something that is on my list to work on in 2020, and is part of the board's renewed focus on transparency. > 4. We should be encouraging the Fedora members to join the CentOS SIGs and vice versa. If the two teams see what each other are working on, they can eliminate overlap, and I have a feeling they would quickly work on merging their efforts into one SIG. Yes, please. But we also need to be careful not to repeat the mistakes of the past. The Cloud SIG in CentOS siphoned off a number of the active members of the Fedora Cloud SIG, effectively killing any Openstack work in Fedora, and we want to avoid doing anything like that going forward. We want to merge/combine effort, not force people to pick one project or the other. Matthew mentions else-thread that we need to figure out how to get our SIGs to work together, in ways that don't just mean that everyone has to do twice as much work. I'm looking for some space/time at FOSDEM where we can kick off this discussion and see what needs to happen. > 5. The process to contribute should be made a lot easier. As an example, I have a patch I want to submit to the Jetty project. Their process is clearly defined, and the only holdup I am having right now is getting the internal approval from my employer to contribute (the normal review processes). With CentOS, I'm not sure what I can contribute to, and what I need to contribute to RHEL or Fedora. I also find that bug reports to all three go un-touched for years at a time. This is definitely something that we're trying to address with CentOS Stream, and we appreciate everyone's patience as we move towards that goal. The RHEL process is enormous, in terms of people, and steps, and all of the mechanisms and tools built around it, and CentOS's heritage is as a rebuild of that, not as a place for innovation. -- Rich Bowen - rbowen at redhat.com @CentOSProject // @rbowen 859 351 9166