Using membership roles to control event details and levels of event pairing participation

[bengineerdavis]

Related slack discussion: https://codebuddies.slack.com/archives/C04BRN86J/p1598189554024000

After scanning through 137, 138, and 139, I feel confident that these ideas could contribute to the discussion of pairings and maximizing participation and follow-through.

Motivation:
Using our v2 "Hangouts" I recently got a notice that someone had added themselves to a zoom meeting... for finished hangout already a week old. It bothered me how little control I had over what information I could and could not share for a public event and also that there was no way to 'sunset' an expired event so that those details could be removed, or to properly and prominently highlight to prospective viewers that the event was live or over.

I was reminded by how nice the "waiting room" feature is of Zoom. I also use facebook a lot and have run groups before, and they have great levels of control for how members and other admins/mods are added. Then it occured to me that a pairing could be treated more like a disposable/ephemeral group, giving us the best of both worlds--an easy way to schedule with others, integrate our favorite conference tool(s), have finer-grained controls to cover a spectrum of collaboration within the CodeBuddies-verse, and keep an "expiration date" on old pairings to effectively expunge personal information from prying eyes.

1. Original Text:
   " Feature idea for hangouts: Some people may prefer to share the event publicly, but be more discerning about who joins. Perhaps we can add a 'request to join' button so the organizer can approve additional collaborators and also let the organizer add addition organizers/moderators so that approval and event management can be share by multiple persons. This would also mask details like a zoom link or maybe keep participants names hidden? I could see this expanding on prior observations by us to control who is active in a stream, but leave it open for anyone who wants to join the 'audience'.

2. Linda's Question:
   "First impression: really like this idea!Should this “request to join” button be a default part of all public hangouts, or only the type of hangout that’s in-between “fully public” and “fully private”?Moving discussion for this to a GitHub discussion post in /frontend is good 👍:skin-tone-3: — thanks. (Feel free to share link in here of course) "

3. Elaboration:
   As I was thinking about a request to join button as an interactive way for hosts to approve additional pairing members, I started to think about roles and how they could be an effective tool for me as an event host/admin. In my experience, most online forum membership breaks down into basic categories: (Listed in descending order of escalated privileges)

• Members: Anyone already accepted into the group, and can see resources that would be public only within the group, as well as public to the world at large.
• Moderators: Those that can manage other members and (most times) have varying levels of editing power within group resources and assets. They can also add or remove other members or set policies towards such. They can see resources that would be private even within the group, or have access to specific channels.
• Admins: Those who created the group and have the power to remove it. (And also have moderation powers).

Regardless, making a clear delineation between those that can make changes to the pairing, those that can interact within a live pairing (such as being broadcast by video/audio) will make it easier to understand and define the pairing's purpose, and let people improvise or adjust pairings in real time.

I want to translate this a little bit for pairings and the dimension membership: (Listing in descending order of escalated privileges)

• Public: Any interaction, data, or other assets that can be accessed without joining a pairing. This would default to the date, time, and summary of the pairing. Not sure if we want this to be public to those who are signed in to CodeBuddies, or public to the world.
• Audience: Any observation of the pairing while the pairing is "live", but no interaction(?). Audience may participate, but cannot be in the "live" discussion, as such the Zoom/Twitch broadcast.
• Member(s): Any interaction (access to a codebase, the link to the Zoom chat, etc), data, or other assets that can be accessed after joining a pairing. This will default to accessing details that will let them.
• Host(s): Any ability to edit interaction, data, or other assets that can be accessed before, during, or after joining a pairing.

I also want to expand the dimension of pairings and time:

• Planning and Proposal: when the Host is established and pairing details are added (required for pairing to exist?).
• Recruitment: when the Host shares their Proposal with CodeBuddies and may add one or more additional Hosts and Members to the proposal during discussion and available interest.
• Creation: Pairing is made with confirmed details (date, start time, duration, summary, goal(s)/agenda, (streaming) platform, and other assets) transferring one or more Hosts or Members (not sure how we wanted to handle a 'pairing of one'). This is an opportunity for Audience to sign up or request membership status within the pairing. It would be neat at this stage that events with additional Hosts and Members get a notice in their private from the originating Host with details and a link to that pairing.
• Negotiation: After everyone is added, the details are defined, but details can also be tweaked. ("Can't make this time"; "we should do this other thing", "let's use Google Meet instead", etc.).
• Broadcast: The "live" event.
• Wrap-up: The details Host(s) want to leave Public, such as "Today I learned".

I had more thoughts on this, but brain power is running out at the moment. Thanks in advance :)

[bengineerdavis]

As for public vs private: going by the above, any pairing is public as long as it allows the Audience to access the pairing. Private is the default for events that are not shared with the community and can only be seen if invited.

[bengineerdavis]

Additionally, we could provide even finer-grained details for Members, so that some Members can talk in the broadcast, but others may also be allowed to work with the Host on code directly, such as VSCode Live Share, or GitDuck. We could also provide templates for different types of Host use cases.

[lpatmo]

I would leave this for a future iteration, once hangouts become popular. At the moment I think a larger problem is finding enough participants for a hangout rather than building features for fine-grained permissions. :)

Also, the default API I'm still assuming is Zoom, but we'd let the host(s) choose an optional alternate way to meet like using GitDuck , VSCode LiveShare, Google Meet, etc.

Note to self: another thing I need to add to user stories is the idea of giving guidelines to the participants re: best practices for coding or pairing together.

[tgrrr]

It sounds to me like sensible defaults in order might be:

1. Public (default) - anyone can join and contribute
2. Member(s) broadcasting their session (others can watch)
3. Private - invited members only

I'm a big privacy advocate, but I feel like spending the entire meetup doing admin for members joining on Zoom and other platforms would be a big time-suck.

[tgrrr]

A good first step for this would be to hide the link to the meetup 24 hours after the event (unless it's a permanent link, eg. it's a recurring event @bengineerdavis

The benefit would be that members weren't accidentally waiting for a meetup in the wrong timezone or on a wrong day of the week.

New user story #1
A user joins codebuddies
They don't correctly setup their timezone (for whatever reason)
They try to join a meetup on GitDuck, Google Hangouts, or Zoom
They sit waiting for people to turn up
They leave and don't come back

New user story #2
A user joins codebuddies
They don't see the date the meetup was scheduled for correctly.
They try to join a meetup on GitDuck, Google Hangouts, or Zoom
They sit waiting for people to turn up
They leave and don't come back

[tgrrr]

Just posting another user story that I think we should cover:

New user story #3:
Current members start up a weekly meetup for React/Go/Python
The CB meetup gets closed/moved in a Slack channel or PM
At the same time, a new member joins and sees the calendar invite
They eagerly join the Zoom / Google Hangouts room on the day, and nobody shows.

[lpatmo]

Re: weekly meetup... we haven't yet discussed the idea of letting users schedule a recurring meetup that'll be on the calendar until X date. I personally shy away from it and prefer that we have a "duplicate" button (like we currently do) for hosts to click on to explicitly schedule the next meetup, to make sure they'll be there.

In one of the user stories on #138 (a long page of threads ha, sorry) I also raised up @bengineerdavis's proposal to have a "request to join" button, which hopefully will mitigate risks that a participant will show up without one of the hosts there, since the host will have to explicitly accept that invite.

---

Tangential side note re: groups... I've been thinking more and more that instead of what we currently have on codebuddies.org/groups, v3 groups (which TBH are far off in the future) when we get to it should have an explicit start/end date. And if the group dies out in the middle, that's fine. But it should end at some date, and not continue forever, because that gives rise to the user story you described where a new person eagerly joins a group but it hasn't been active for some time.

[lpatmo]

Public: Any interaction, data, or other assets that can be accessed without joining a pairing. This would default to the date, time, and summary of the pairing. Not sure if we want this to be public to those who are signed in to CodeBuddies, or public to the world.

I lean towards public to the world, but a user can only interact if they're logged in.

Audience: Any observation of the pairing while the pairing is "live", but no interaction(?). Audience may participate, but cannot be in the "live" discussion, as such the Zoom/Twitch broadcast.

Ah, so an audience would be relevant for hangouts of type 'presentation' or watch me code, assuming we have the following types in v3:

pairing (minimum of 2)
presentation (minimum of 2)
cowork with me (minimum of 2)
study group (minimum of 2)
watch me code

Member(s): Any interaction (access to a codebase, the link to the Zoom chat, etc), data, or other assets that can be accessed after joining a pairing. This will default to accessing details that will let them.

Host(s): Any ability to edit interaction, data, or other assets that can be accessed before, during, or after joining a pairing.

Sounds good -- and by "pairing" you're talking about a "hangout" or a "connect". lol, so many ways to reference the same thing