Objective: Split the existing chat channels into two distinct sections: one for users on Ethereum Mainnet/public networks, and another for those developing private networks using Besu.
Rationale: This modification aims to ensure both types of users receive appropriate support. By segregating the channels, we can create a focused environment for relevant discussions, debugging, insights sharing, and collaboration. This will also enable new developers and contributors to assist each other more efficiently.
Potential Drawbacks: Users may initially find the new structure confusing, and the channels may appear more segregated. Besu maintainers may need to context switch more frequently to support users in the right place.
Mitigation Plan: To address these issues, we could create a more comprehensive onboarding guide in the discord to navigate the new structure. We could also consider new discord roles to tag certain sets of maintainers (i.e. public-focused maintainer)
Thoughts and feedback on this proposal are welcome!
5 Comments
Ry Jones
I like this - let me know how I can help.
Simon Dudley
I'm not yet convinced there's a need for this and I think it will add friction for the users (and maintainers who have to redirect people).
Given Besu support is already split across two multi-project Discords making it harder than most clients to find the right channel, I think there is value in continuing to have a simple "besu" channel without further signposting requirements.
I'm interested to hear what problems people are having with the current setup.
> This modification aims to ensure both types of users receive appropriate support.
I find the questions usually make it obvious which type of support is required and sometimes there's questions that are relevant for all use cases, such as peering, that both types of users would benefit from reading.
Something similar to this was previously attempted during The Merge when there was an influx of mainnet stakers. It didn't really work: neither type of user commented in the appropriate channel.
Maybe good channel naming and descriptions would help, but I'm not sure how many people pay attention to that.
If we do this, I think "besu-stakers" might be a better way forward rather than public/private as stakers aren't really familiar with this terminology.
Matthew Whitehead
As a predominantly private/permissioned chain user I have wondered about this over the past few months since a lot of the discussion on the core Besu channel is mainnet and consensus-client related. However, I agree with some of the downsides mentioned above. Depending on how the split is done, it might also become harder for someone to know where to put a question that applies to both (common CLI args, logging options etc). And since Discord doesn't let you move messages between channels (as far as I'm aware?) once a question is in the wrong channel it needs re-asking on the correct one.
I think it might come down to how the split is made. Happy to be involved in the discussion on the community call.
Karim Taam
I think the questions and bugs related to private and public networks are generally different and I think that it can cause confusion for users. Will this problem happen to me too if I'm on mainnet? Is this a mainnet bug ?
moreover I think that for developers it is also difficult because in general the questions linked to private networks are more numerous than the questions linked to mainnets. if a person is currently working on the mainnet and may want to focus on the bugs that we have on the mainnet but they find themselves searching in a long thread of private network questions
even on the documentation we do not mix the two parts so it seems logical to me to separate it also on discord
a basic naming I think could do the trick
besu-private-network
besu-public-network
Idk if we can use that https://support.discord.com/hc/en-us/articles/4421269296535-AutoMod-FAQ to display a message to the user if someone is sending a question with ibft to the wrong channel
Like that we will educate user and we will not have wrong message in wrong section
Matt Nelson
Notes from the contributor call on 10/3/2023