After a chat with Gavin on gitter, I’d like to propose a cleanup of community communincation channels.
This proposal solely focuses on establishing a streamlined and centralized communication platform for members, developers and other people contributing to the Jenkins community, who previously used lesser frequented IRC channels or Mailing lists.
The proposal doesn’t focus on development related components like Jira, GitHub, etc. or official channels like Twitter, YouTube, etc.
The vast amount of existing communication channels almost makes it impossible to find an answer to a topic, without searching more than a couple dozen of services and is pretty limiting in terms of reaching out to other community members outside your communication bubble, not to mention the monitoring and moderation of widespread channels.
This proposal promotes the usage of the forums (community.jenkins.io) for feedback, ideas, suggestions, announcements and posts from SIGs, etc., like the forums are already used.
It also promotes the usage of Matrix bridged to Gitter (gitter.im/jenkinsci/home) for chats with other members of your plugin, SIG, etc., like Gitter is already used. Our gitter space currently hosts 81 plugin and SIG channels and a general Jenkins channel with more than 10k members.
Cleanup Proposal:
Service
Channel
Strategy
Share/Acceptance
Reasoning
IRC
#jenkins-infra
Switch to Matrix/Gitter bridge
28 connected members
General chat for the infra team, requires coordination with infra team, but can live on matrix.
IRC
#jenkins-release
Switch to Matrix/Gitter bridge
16 members connected
The release team can coordinate their work on the Matrix/Gitter bridge too
38 members subscribed, a plenty of spam posts with no real interaction
The forum offers a category for language groups
Phase 0:
This proposal is voted on by SIG people affected, whether they want to move on to the proposed service.
Services that aren’t governed by SIG people are decided upon overall consensus.
Phase 1:
Remove without replacement/Move to forums: A final post is published on the mailing list outlining that the list is going into read-only mode pointing to the forums and the category to use.
Once the post is published, the mailing list is turned into read-only mode.
A one liner is added to the group description pointing to the final post.
Phase 2:
Switch to forums work in progress: A transition of a mailing list to the forums is currently ongoing.
I’d like to hear some feedback and ideas about this proposal to hopefully cut down communication channels and focus on what people actually use and interact with; Gitter/Matrix bridges and the forums.
While we can export mailing lists to .mbox files, and they can be imported into discourse. The existing community support for that is for shell access to discourse itself. Since we are using a sponsored instance, we can’t really do it. If we want to import old discussions (Mark and I figure we don’t), then we’d either need to rewrite the script to use APIs, or to mark form as read-only, download dump, import mbox, then send import back to discourse support team to re-import
As I updated the helpdesk ticket, i sent out a request to gitter support for migrating one of the minor old gitter rooms to a matrix room, so we can try bridging/integrations/etc.
I’ve already setup some notifications for tags and messages here. If someone posts to sig-docs it posts to the docs gitter channel. Anything in ask a question goes to jenkins/jenkins channel, etc. Can easily setup more notifications if need be.
irc has like 5 people in #jenkins, and like maybe 10 in #jenkins-infra.
And weren’t you the one raising a big fuss about how the mailing list was sending a bunch of things to spam?
The current setup is not working. Mark is pretty much the only person on users mailing list. When people post the wrong mailing list, we all either ignore them, or shout at them that they are on the wrong list. It is not great experience for non regulars. At least with discourse we can move things to the right place and get people talking to the right people. I would say the users mailing list is generally ignored for many years.
Right now there’s also a major issue with discoverability. With everything all over the place, its hard to attract new contributors. Most things are invisible unless you know where to look.
I can’t speak for Alex, but my goal is make it easier for users to go from consumers to contributors, which is why i keep pushing for centralizing as much as possible.
Right now there’s also a major issue with discoverability. With everything all over the place, its hard to attract new contributors.
Why was this never an argument used to stop the wild sprawl of community channels in the first place?
Why does Gitter in particular not have an inherent problem with discoverability? Rather than 4 IRC channel there are many dozens. I just randomly went to https://gitter.im/jenkinsci/ (expecting that to be the list of Jenkins channels) and it’s a dead channel someone apparently created by accident.
What are your plans to ensure our code of conduct is enforceable across all these community spaces?
I wasn’t involved? I didn’t even realize people moved out of the main channel till like 3 years ago.
Alex’s chart and my efforts are to reduce all those spaces into manageable amounts. The table Alex put together was to shut down a bunch of the quiet mailing lists back into a single space. Merge the gitter/IRC/matrix into one space per channel (so #jenkins and jenkinsci/jenkins get bridged and merged). The idea is to reduce, merge and shutdown things.
For the infra, we’ll throw this topic and see what the team members think and we’ll let you know folks.
Personnal note: That is a huge work but it make sense. The method seems really good and comprehensive. Just take it slowly please: it is northern hemisphere’s summer meaning a lot of people going off for holidays to leverage frustrations.
It’s not about attracting new people only, services like mailing lists or IRC may not always be as attractive for SIGs and groups of people as you may think they are…
You aren’t bound to a specific service I guess? You can use your existing matrix setup or log in via OAUTH using GitHub, GitLab, etc. from any device without using an IRC client with a bouncer to stay connected.
That’s not a public channel, it’s available to organization members only. See jenkinsci/jenkins for the public channel.
An overview over all channels is available on jenkinsci/home.
Many repositories have a badge or link in their readme pointing to their dedicated channel.
In case of rule violations, room admins can remove the content or the member from the room or community.
Removed content remains accessible through public archives of channels.
Everyone is able to report harmful content to Gitter through the UI, if detected.
Convenience of use is an argument that makes sense. IRC can be annoying if you don’t have IRCCloud or a computer that’s always on and connected. But Gitter’s mess doesn’t help addressing
Right now there’s also a major issue with discoverability. With everything all over the place, …
Gitter simply combines discoverability issues and everything being all over place in one convenient service.
I have suggest it before GitHub Dicussions but let me suggest it again.
Have you considered replacing all channels with GitHub Discussions Documentation - GitHub Docs and GitHub issues / pull requests. I feel like lately most of the communication is happening there anyhow.
I believe GitHub could even replace most of the security workflows from Jira with GitHub built security issue reporting. Allows for hidden PRs with security fixes.
If you need the chat element that can be replaced with Discussions and editing replies.
Personally I think GitHub has one of the best web notifications and mobile notifications and can easily replace chat.
Prefer well formed discourse on GitHub over trying to go to IRC and ask infra for something. Same goes for mailing list, ewww.
Thankfully the Jenkins infra team has moved theirs to GitHub with great success I might add.
Great work infra team!
Just to be clear, your suggesting to the proposal of reducing/organizing communication channels, is to add even more communication channels (so 3k-ish repos, so 3kish new channels)? With the exception of issues, discourse does everything listed and is in one place.
For developers of a single plugin probably, but that doesn’t engage the community at all, and isn’t great for end users who have to try and find the right space to get help in. And thus they can’t see areas they can offer to help in.
https://gitter.im/jenkinsci/configuration-as-code-plugin is a good example of why I’m against each plugin doing its own thing. It has its own communication channel. Really the only two helping out there are hern and tim, who are both super busy with all kinds of other projects. By being in a centralised place, it would be easier for more people (like myself, mark, etc) to help out more.
so i’m personally -1 on having per repo solutions.
You might use repository discussions to discuss topics that are specific to the repository. If your project spans multiple repositories, you might use organization discussions to discuss topics that aren’t specific to a single repository in your organization.
that definatlly reduces my concerns. Though I’m not on sold on switching to another system after the year of trying to promote discourse. Especially since discourse would work across orgs (infra and non), doesn’t require github, and has all the same features
I had organization discussions in mind, sorry for not linking to it or mentioning it.
GitHub has excellent linking options between issues, pull requests, discussions and release notes. Which discourse does not. You cannot track the what links to what.
You also have the recently released GitHub projects, which provides more opportunities. Thinking of the failed attempts of trying to create a custom solution for roadmap.
You could argue that jenkins infra helpdesk is already their organization discussions although they chose to use issues. However you can turn discussions into issues and issues into discussions. So you get the best of both worlds.
The -1 for discourse is that it is another solution you need to host.
I was never in favor of gitter either, I tried to use it but gave up. Hence why I do not participate in the configuration as code gitter.
Btw this is just my opinions and a simple suggestion. You are free to disregard my word.
Although admittedly my point of view was coming from a wish to unify the forms of communication and fewer systems in my mind is always superior.
So if Jenkins is open source and largely whose who contribute to ecosystem use GitHub on a daily basis. Why not increase the amount of eyeballs and focus them on one source.
This includes Jira, Discourse, Mailing list, gitter, matrix, IRC.
I might have missed a few. I exclude social media sources as they intend to drive traffic to these sources.