Decide on how to structure Discord channels for the sprint about core-sprint HOT 22 CLOSED

Thanks for the feedback @gvanrossum. I was not able to participate in EuroPython this year so I don't know what their Discord server setup looked like. But I'll try to keep the number of channels as limited as we reasonably can to make it easier to navigate. It can be easy to get carried away with the volume of channels if we try to add one for every possible category. Maybe we should also consider not making a text channel for every single voice channel to reduce the total volume a bit.

Since we'll be using a public Discord server for the Sprint (Python Discord), it will contain the existing channels on the server. However, the category for the Sprint will be at the top to make it easy for participants to quickly locate it. If it would be helpful, I could also put together a quick guide before the sprint for joining the server and explaining the channel layout.

from core-sprint.

Let’s see what others have to say.

For me, sprinting is not a spectator sport, and I would object to having the channels public (even read-only).

from core-sprint.

from core-sprint.

I believe this is largely blocked by #1 (on the sign-up form, core devs should be able specify topics they're interested in covering, then we can base the individual topical sprint channel names around that). In the meantime, a basic format like this might be good to start with:

Note that in the above image, each channel has an equivalent voice channel and text channel (in Discord, a channel is either "text" or "voice"/"video", indicated by the icon to the left of the name). I suspect people will primarily use the voice channels during the Sprint, but it's good to have an accompanying text channel to post links in.

Also, more creative names for the channels would definitely be welcome! As long as it's clear what the purpose of the channel is, I think we can make it a bit more interesting than just Social 1 and Social 2. Maybe something Monty Python-themed could work.

Either below those channels, or perhaps in-between General and Social, we can add each of the topical channels for the Sprint (depending on sign-up responses); e.g. "Async", "C-API", "Documentation", "Packaging", "Steering Council", "Windows", etc. As needed, new channels can be easily added or reordered. We might also want to just add generic Sprint N channels in addition to the specific topical ones. But I'd rather start with less channels and add more as needed, to avoid having a bunch of vacant ones that people have to scroll through to get where they want to.

from core-sprint.

FWIW, EuroPython used Discord this year, and as a new user to Discord it was a bit confusing. Perhaps they had too many channels.

from core-sprint.

Would zulip be a better option here which is more familiar to most of us core devs?
I know that we said we're not active there anymore..

from core-sprint.

At least Zulip doesn't look so visually overwhelming; Discord looks like an angry fruit salad to me, and it doesn't seem to have an option to make the color palette milder. (Even though honestly it probably doesn't look too different from Slack, which I used for years at work.)

One of the problems I had with EuroPython's Discord was that the operators were (of course) very experienced Discord users who (sadly) didn't understand why it's hard to figure out for a new user, and answered my complaints with suggestions of magical keyboard shortcuts (which didn't work for me because I have a Mac) or a mention of some concept that didn't help me. Basically they've done a whole bunch of configuration so their screen looks entirely different from mine. (A classic trap for power users to fall into, BTW -- and one reason I tend to avoid tools that require heavy configuration.)

from core-sprint.

@gvanrossum

At least Zulip doesn't look so visually overwhelming; Discord looks like an angry fruit salad to me, and it doesn't seem to have an option to make the color palette milder.

There's not much in the way of color customization (other than using a Light theme instead of the default Dark theme), but one thing that makes a chat less overwhelming and easier to keep up with is using the "Compact" message display setting (Found via Settings > Appearance):

This prevents user icons from adding a bunch of extra noise. I also modify the text font size to 18px, and set a 4px spacing between messages (no space at all between messages makes it a bit hard to distinguish in compact mode).

Default appearance settings:

After:

One of the problems I had with EuroPython's Discord was that the operators were (of course) very experienced Discord users who (sadly) didn't understand why it's hard to figure out for a new user, and answered my complaints with suggestions of magical keyboard shortcuts (which didn't work for me because I have a Mac) or a mention of some concept that didn't help me. Basically they've done a whole bunch of configuration so their screen looks entirely different from mine. (A classic trap for power users to fall into, BTW -- and one reason I tend to avoid tools that require heavy configuration.)

FWIW, while I use Discord a decent amount for various communities and keeping up with some friends, I really have not done any configuration beyond the default settings, other than the above visual adjustments. I also tend to go with just manually clicking on channels in a single window, so any suggestions I'll provide would be from using a mostly default setup without any custom shortcuts.

Also, with the single-category setup that we're using, I'll be able to easily add and delete channels as needed on the spot (with inherited permissions), so we can definitely start with a few to make it as simple as possible, and gradually scale as needed based on the number of independent conversations that are going on. This would be hard to manage with a larger event (like EuroPython), but for something with a smaller group like our Core Dev Sprint (~30+ based on past attendance), I should be able to much more easily cater to individual needs.

If the consensus ends up being to go with Zulip instead because it's more familiar to work with, it wouldn't be the end of the world, but I likely won't be able to help much with setup/operation there since I've never used Zulip (other than very briefly checking out our presently inactive server).

I think there's also a significant value from a community engagement perspective in being able to use a decently populated existing server to host the event. We would have privacy in the dedicated event channels and the Sprint would function similarly, but I think it would be really cool for others to be able to see us in action; as opposed to just being on our own Zulip server with little to no visibility.

from core-sprint.

For me, sprinting is not a spectator sport, and I would object to having the channels public (even read-only).

Just to be clear, by publicly visible I just mean seeing us present in the voice channels and having the event on a public server, not being able to read what we enter into the text channels or listen to what we say. I did have some consideration of having one public read-only text channel, but that would be separate from the others and only done with consent from the participants.

from core-sprint.

I would personally fear DM attempts from fans. :-(

from core-sprint.

I would personally fear DM attempts from fans. :-(

In order to prevent that, you would go to Settings > Privacy & Safety, and disable "Allow direct messages from server members" and "Who can add you as a friend":

I personally use those settings because even I receive a decent amount of DM attempts on the server from people looking for one-on-one Python assistance.

from core-sprint.

I also prefer Zulip myself. And I know that a number of us are already set up on Python's Zulip.

from core-sprint.

Could we automatically configure the sprint members this way and also allow them all to DM other sprint members?

(TBH I doubt Zulip could do this either, but there are way fewer people already on there, so it’s less of a problem.)

from core-sprint.

Could we automatically configure the sprint members this way and also allow them all to DM other sprint members?

I don't think there's a way to do this 100% automatically, but as long as everyone sets the above settings and has one friend in common, we could fairly easily add each other via right clicking their name in the voice channel and adding the person as a friend. It just requires that one person acts as an intermediary (such as myself), and have everyone send a friend request to that intermediary before adding others in the sprint. Discord significantly limits automation of user accounts and friend requests, as it reduces spam.

from core-sprint.

So Discord’s security model doesn’t have groups?

from core-sprint.

Discord does have groups that are implemented as "roles" specific to the server (which is what we'd use to give core devs permissions to join and participate in any of the text/voice channels, as well as myself and Mariatta the ability to create/remove channels within the sprint category), but that doesn't affect anything outside of the server, such as DMs.

from core-sprint.

Okay.

from core-sprint.

from core-sprint.

@malemburg Yep, that's what I was referring to in my earlier comment. I believe Guido was referring to a way to have it set automatically and allow each core dev to communicate with one another, rather than having to set it up manually in the settings and then adding each other.

Note that an alternative option could be to host the sprint on a private Discord server. It would require slightly more setup on my end (such as reaching out to Discord for a server partnership, so we have access to the better performance voice servers) and would rule out any form of community engagement via Discord that we'd potentially gain from using a popular public server, but that might be something else to consider. As I see it, we currently have three potential options for the platform to use for the sprint:

1. Python Discord
2. existing Zulip server
3. New private Discord server

Feedback from other participants on their preferred option would be much appreciated. At this point, I'd prefer to wait until we decide on the platform before asking anything else of Python Discord as far as setup goes, particularly since it seems to be leaning in the direction of using the existing Zulip server.

from core-sprint.

In order to get some more community involvement, the private
server could be setup with channels which are open to the
general public and other which are core dev only. Discord
permissions are pretty flexible to allow for such configurations.

I think if we want to go with the community involvement route, there's really not a significant benefit for using our own private server (for the purposes of the core dev sprint) compared to using Python Discord, as it already has a partnership with Discord for improved audio/video quality, and they have extensive in-house moderation tools (some of which I've personally helped to work on). The main reason for us to consider using a private server is so that core devs don't have to configure their privacy settings and can add each other more easily.

I do quite like the idea of automated signups though for core devs, I'll have to look more into the solution used for EuroPython to see if a similar approach might be worthwhile for us to consider. Thanks for the insights!

from core-sprint.

Yesterday, I did a workshop meeting with the admin team and owners at Python Discord, and this was the eventual format we came up with:

(Categories are collapsed, to fit all of them within the screenshot. Each one has at least one pair of text and voice channels. The categories "STDLIB" and "Other" will likely have the most channels within the category.)

Essentially, we created a general category for containing announcements, general info about the sprint, and an initial text channel for participants. Then, there are 5 category sections intended to be used for each project worked on during the sprint. The initial category names are the most popular projects (based on sprint projects).

To cover the other projects, we will configure the permissions to allow organizers & core devs to change the name of a category that is not currently in use. This will allow participants to see what project is being worked on and potentially join in. If there are 5+ simultaneous separate projects going on, we have an overflow "Other" category, where organizers & core devs will have the ability to add additional channels that should be named based on the project being worked on (with a text and voice channel pair).

This was done in order to strike a balance in having enough separate channels for participants to simultaneously use, without having too many channels/general visual clutter to keep track of (especially for those less familiar with using Discord, this was taking @gvanrossum's feedback into consideration).

Also note that this is not set in stone by any means, but instead serves as an initial draft of the sprint channel structure. Based on feedback in the coming weeks leading up to the sprint, we can make adjustments as needed. With it being the first ever virtual core dev sprint, we're going into it with the assumption that changes will likely need be made dynamically throughout the event.

(Information on creating channels, renaming categories, general guidelines, etc. will be covered in the upcoming Discord sprint guide I'm working on, assuming this format is approved by the other organizers in our upcoming meeting (Sept. 30th) when we do a walk-through of the channels.)

from core-sprint.

Seeing as there is less than a week remaining from the start of the sprint (Oct. 19th) and with no recent feedback, I'll proceed with closing this.

from core-sprint.