Participation/permissions/sharing UX, user job stories defined

[ackernaut]

Once upon a time the meeting members for any meeting were equal to the team members. They were one and the same. The clouds and the bushes…they are also the same. Except the bushes are green.

Now meeting membership doesn’t equate to team membership. How so? The list of meeting members is made up of any team member who’s visited the meeting at least once. Only team members have access to the meeting. We don’t include team members who haven’t visited the meeting. I said that already.

This helped with some UX nuances but created some other ones. Here’s an example:

• At Parabol many of us are on many of the teams regardless of whether we join the meetings. Facilitators had to navigate past our pretty faces during the Icebreaker or Solo Updates phases on a regular basis because of absenteeism. This is probably an edge case. Now there’s a nice tidy list of folks who are actually at the meeting, and maybe a few absent folks who viewed it in async.
• Previously we could randomize the list of team members for the order of sharing in the Icebreaker and Solo Updates. Now we have a problem where the Facilitator always goes first, see Person who started the meeting always goes first #4772

Here’s a starting list of things to think about:

• Who sees the meeting summary? Who gets the summary email? Who can see it on the timeline?
• Do we close threads once a meeting is over? Bug: Non-meeting member cannot go back to the meeting thread and make comments #4688
• Can new team members see meeting history? New team members can't see meeting history #4527
• Who can see a meeting? Design Meeting Permissions UI #4540
• When folks see a partial list of folks marked ready or a partial number of cast votes, they may not realize that absent folks who connected at least once are being counted, see Designed participation status menu (or alt. patterns) #4916
• In the future how might teams share out things to other org members, like a roll-up of stand-up content? Next concepts for stand-up meetings created #4771
• How could our ancient summary UX be improved? Summary UX explored #3622

We don’t want to boil the ocean, but it may help us to establish some hard and soft edges between meeting participation, team membership, and org-wide sharing — so that there’s less conflicts and regressions to resolve in our system if we just take on UX nuances ad hoc without any structure. I’m suggesting:

Acceptance criteria

• (If this is bloated in scope we can mark it a discussion, pare it down, and find a smaller next step. But I only imagine more regressions in system logic if we don’t revisit our base principles and solve for existing and assumed job stories from that base.)
• Wrote a list of user jobs stories that reflects assumptions on how meeting participation, team membership, and org membership affect business logic, permissions, and async/sync behaviors
• Defined and refined any working design principles in our system that we’ve been using, making any suggestions on how to move forward
• Suggested some first design issues to solve for the most important job stories (based on validating risks, or exploring strategic opportunity, or unblocking roadmap work, etc.)

Estimated effort

• 16 hours

[drewhousman1010]

A user 🔒 says:

It's hard to find past summaries and too complicated overall to find relevant information about past meetings.

I'd like to have everything organized by team. You could click your team on left and instantly see active meetings and past meetings.

"timeline" feels like it would contain irrelevant events, it does not feel like a place where you'd find specific meeting info.

[ackernaut]

See discussion #5670

[jordanh]

Closing in favor of #5670 – I think these are overlapping enough that executing #5670 would start us down the right track