Closed Bug 1020356 Opened 10 years ago Closed 10 years ago

Design for hosts to add mentors / co-hosts to events

Categories

(Webmaker Graveyard :: Events, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: matt, Assigned: cassie)

References

Details

(Whiteboard: [design] [june13] [events] [june27][events-mentor])

Attachments

(1 file, 1 obsolete file)

      No description provided.
Assignee: nobody → cassie
No longer depends on: 1019931
Whiteboard: [june13] → [design] [june13]
We should be clear about designing for co-organizers versus mentors as two different user types.

As discussed with Gavin and Kate in IRC:

* Co-organizer is someone who is organizing the event with you so would need access to the attendee list, ability to edit event settings like location, time, etc
* Mentors are input by the organizer/s and don't get additional permissions, but are listed on the event detail page.

Brett / Matt does that ring true to you?
Flags: needinfo?(matt)
Flags: needinfo?(brett)
That makes sense to me, all three should be counted as contributors.

Also we should make those distinctions clear to event host.  Is "mentor" the right word?  This is someone who will be animating the event/working closely with learners/giving a talk etc.
Flags: needinfo?(brett)
Attached file https://redpen.io/md3d8f0edf5a617668 (obsolete) —
Added a 'People' section at the bottom of the Add an Event form where you can add co-organizers and mentors.

This exercise definitely raised a question about when email confirmations needed to be sent. All the time? Or only to unregistered users? 

I definitely lean toward the former, especially since this info will be displayed on the Event Detail page. Imagine if someone were creating an event and they wanted to list someone who was high-profile as their mentor or co-organizer -- but that person was not aware of the event, or was too busy... The onus should be on the system to prevent that kind of misuse. On the flip side, there's also an opportunity here to suggest mentors and have a kind of request / confirmation system built in. Much further down the road :)

For now, it *would* be awesome to have the system recognize emails that are already associated with a user account and be able to automatically load in the profile pic and link to their profile.
Attachment #8435995 - Flags: feedback?(matt)
Attachment #8435995 - Flags: feedback?(kate)
Attachment #8435995 - Flags: feedback?(gavin)
Attachment #8435995 - Flags: feedback?(brett)
Put some feedback in RP.

My main thought is that we should add by username instead of by email. Co-organizers will have to have an account to edit events or be featured on the event detail, and mentors will also need accounts to be featured.

Basically there's nothing that gets accomplished by adding a person via email unless they sign up for an account.
Attachment #8435995 - Flags: feedback?(gavin) → feedback-
(In reply to Brett Gaylor [:brett] from comment #2)

> Is "mentor" the right word?  This is someone who will be animating the event/working closely
> with learners/giving a talk etc.

+1 that "Mentors" is potentially confusing here

Could be unpacked as: "Other speakers, co-presenters or mentors"

I'll try to think more on the copy Monday.
Flags: needinfo?(matt)
Comment on attachment 8435995 [details]
https://redpen.io/md3d8f0edf5a617668

I don't see anything that throws too many red flags for me,

I'm not sure I understand what the reservations are behind allowing users to look up other users by email, if the user has the email first, particularly for -authenticated- users.

Keep in we'll need to write emails and build in confirmation hooks etc, there is quite a bit of work here.
Attachment #8435995 - Flags: feedback?(kate) → feedback+
I added a thought to Redpen, thought it was worth throwing here too:

I was thinking of the list of emails/users as only viewable by the organizers or person adding the event – the usernames would only show on the events details page (NEVER the emails) if the mentor had confirmed their participation via an email link.

The ability to add by email allows us to get new users into our system, which is THE major goal for this update. It allows us to send an email to prompt them to sign up without putting the onus on the event organizers to ensure their mentors are registered with Webmaker.
That makes sense to me.

What about the case where someone adds a mentor at a certain email but that mentor uses a different email address on Webmaker?

e.g. my account is k88hudson (kate@mozillafoundation.org), but someone added my email as k88hudson@gmail.com

Do I just have to manually tell them to change it?
Really good question.

MVP – yes I think the organizer should manually add someone by their preferred email. Users constantly have to do this for anything Google so I don't think that's an unreasonable expectation.

Was going to file a bug to consider for future evolution of this feature, but how would you even verify that the user with another email was the same person? Would this be covered by login flows that allow users to choose which account they want to sign in with?
Blocks: 1022700
In our privacy policy ( https://webmaker.org/privacy ), we say:

> What do we mean by "personal information?"
> 
> For us, "personal information" means information which identifies you,
> like your name or email address.
> 
> Any information that falls outside of this is "non-personal
> information."
> 
> If we store your personal information with information that is
> non-personal, we will consider the combination as personal
> information. If we remove all personal information from a set of data
> then the remaining is non-personal information.

So, username is public and the email is personal. And if you combine
the two, then the combination is personal. 

Later on in the privacy policy we say:

> When do we share your information with others?
> 
> When we have gotten your permission to share it.

If the co-organizer and mentor flow works as :cassiemc stated, where
we prompt the user being emailed for their permission to be added to
the event and make it clear that it will show off their username on the
public page, then I think we're in the clear, with regards to privacy.
Additional UI for how this information appears on the Events detail page. With notes.
Attachment #8435995 - Attachment is obsolete: true
Attachment #8435995 - Flags: feedback?(matt)
Attachment #8435995 - Flags: feedback?(brett)
Attachment #8437140 - Flags: review?(kate)
Attachment #8437140 - Flags: feedback?(brett)
Status: NEW → ASSIGNED
Blocks: 1010426
Comment on attachment 8437140 [details]
https://redpen.io/md3d8f0edf5a617668

Looks good, I added some suggestions about moving stuff around/minor details
Attachment #8437140 - Flags: review?(kate) → review+
* Cassie: suggested copy re: supporting copy under "Mentors" section

"These could be other speakers, co-presenters or mentors. They'll be listed on your events page, but won't have the ability to edit the event details. We'll email them to confirm their participation."
Revised to:

"These could be other speakers, co-presenters or mentors. They'll be highlighted as guests of honour on your events page, once they confirm by email."
Co-organizer(s)

"Co-organizers can help you edit your event page. Including editing the date, time and location."
Have updated the copy and integrated Kate's comments. New redpen is here: https://redpen.io/md3d8f0edf5a617668

Marking resolved. We can do any further iterations in code. On to the build in bug 1010426 !
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [design] [june13] → [design] [june13] [events-mentor]
Whiteboard: [design] [june13] [events-mentor] → [design] [june13][june27][events-mentor]
Whiteboard: [design] [june13][june27][events-mentor] → [design] [june13] [events] [june27][events-mentor]
Comment on attachment 8437140 [details]
https://redpen.io/md3d8f0edf5a617668

my feedback is that im happy its shipped!
Attachment #8437140 - Flags: feedback?(brett) → feedback+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: