999112 - Allow unvouched users to join groups

Status: NEW

(Participation Infrastructure :: Phonebook, defect)

Description

[colin]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Firefox/30.0 (Beta/Release)
Build ID: 20140415004003

Steps to reproduce:

Unvouched users are currently not able to join groups. According to https://bugzilla.mozilla.org/show_bug.cgi?id=992849 this is the case (and probably intentional) since curated groups were introduced.

With the tablet contribution program we're shipping tablets to both vouched and unvouched users. We'd like to allow them all to join the mozillians group. Unfortunately that's not possible for unvouched users.

Comment 1

[Asa Dotzler [:asa]]

William, this is the bug for the item I raised a few days ago.  If it's possible to get this changed in the next week or so, that would be ideal.  If it's too big a change to roll out across the whole of Mozillians, maybe an optional flag that group owners can set so I could open this one without having others necessarily affected?

Comment 2

[Justin Crawford [:hoosteeno] [:jcrawford]]

:sancus is going to have a look and get back to us about the feasibility of supporting this. What are the external time constraints that this work impacts? If not possible in a week, is it still helpful in 2, or by that time would it be too late to help?

Comment 3

[Asa Dotzler [:asa]]

(In reply to Justin Crawford [:hoosteeno] from comment #2)
> :sancus is going to have a look and get back to us about the feasibility of
> supporting this. What are the external time constraints that this work
> impacts? If not possible in a week, is it still helpful in 2, or by that
> time would it be too late to help?


Yes, this will be impactful as soon as we can get it. If we don't have it for a couple of weeks, we'll just let folks know that we're working on it and will have it soon. Sooner the better but I understand this is a late-breaking request. We'll manage :D

Comment 4

[Andrei Hajdukewycz [:sancus]]

So this is somewhat non-trivial. The problem is that right now our UX assumes that unvouched users cannot access any group-related pages no matter what. This creates a number of new interactions/situations we need to account for:

* In order for them to be able to join groups, we'll have to allow unvouched access to the group browsing page, and the group pages themselves. Likely, we'd only want to let them see groups that have set the option to allow unvouched members. 

* Privacy issues: unvouched users in a group shouldn't be able to see profiles in the group listing that aren't set to private, etc. Also, we'll likely need to add checks to prevent an unvouched user from becoming a curator. Right now they implicitly can't because they can't join groups.

Letting unvouched users into this part of the site is actually a fairly major reversal of our current permissions allowed to unvouched users.

A patch for this may be doable this week, but I wouldn't be comfortable letting it go to prod without at least an additional week or so of QA and settling in on dev/stage.

Comment 5

[Andrei Hajdukewycz [:sancus]]

I'd also like giorgos to weigh in on this since he's more familiar with the groups code than me, I may have missed some implications.

Comment 6

[William Reynolds [:williamr]]

Sancus, thanks for looking into the implications.

To offer a potential solution to comment 0, the people participating in the Tablet Contribution Program could be vouched. My understanding is that many of these people are already Mozilla contributors, and those who are not have offered to making contributions in the program. That feels like enough of a reason to vouch for them.

Asa, how do you plan to use the Tablet Contribution Program group? As groups currently exist, you will be able to see the list of members, a count of people in the group and a list of skills that the members share. There is no communication mechanism other than having access to each person's profile.

Comment 7

[Asa Dotzler [:asa]]

(In reply to William Reynolds [:williamr] from comment #6)
> Sancus, thanks for looking into the implications.
> 
> To offer a potential solution to comment 0, the people participating in the
> Tablet Contribution Program could be vouched. My understanding is that many
> of these people are already Mozilla contributors, and those who are not have
> offered to making contributions in the program. That feels like enough of a
> reason to vouch for them.
> 
> Asa, how do you plan to use the Tablet Contribution Program group? As groups
> currently exist, you will be able to see the list of members, a count of
> people in the group and a list of skills that the members share. There is no
> communication mechanism other than having access to each person's profile.

As I understand it, we're using vouched status for more things these days, including participation in some non-public meetings.  I'm not sure it's right to vouch for people we don't know that well yet.  

My hope was that groups would allow Mozillians to find each other. A tablet contributor in India might look to see if there are other tablet contributors nearby or a contributor working on writing L10N patches might find another Mozillian with a tablet to test those patches.

Maybe we should just use Facebook?

Comment 8

[Giorgos Logiotatidis [:giorgos]]

As :sancus said this is going to be non-trivial as the code is designed on the assumption that groups are not accessible by unvouched users. 

But even if we allowed them to join a group I'm not sure it'd fit your needs:
 - Unvouched users are treated as public users when it comes to permissions 
 - That means that they are not able to see information that's not marked public
 - Therefore even if someone is in the same group with an unvouched user, but has no public info, the unvouched user will not be able to identify them.


As a long term solution I suggest that we keep groups the way the are now, but we move forward with the authorization refactoring and then introduce a "Contributor" level.

"Contributors" are exactly the category Asa needs. People that we close to Mozilla, working on our products but they are not identified as Mozillians (yet). But they still need to be able to identify other contributors or mozillians and the other way around.

Having that we can use a combination of "Mozillian" and "vouched status" to allow participation to non-public meetings and other Mozillians-only activities.

Comment 9

[Caspy7]

It sounds like the way forward with this would be the additional third category approach, yes?
Wondering if there has been any progress on this?
I ask because we were having a discussion about privately distributing builds to Flatfish recipients and someone made a probably-good recommendation to put downloads behind Persona based on a user's mozillian group.  As I understand, this would likely work except for this issue.
https://discourse.mozilla-community.org/t/distributing-builds/412/3