Improve UX explanation of group privileges so all users know what the mean and who is at each level

NEW
Unassigned

Status

Participation Infrastructure
Phonebook
4 years ago
11 months ago

People

(Reporter: gerv, Unassigned)

Tracking

(Blocks: 1 bug)

Details

(Reporter)

Description

4 years ago
In bug 909235, mbrandt wrote:

"Gerv - you make a valid point. The notion of a 'privileged' group is /not/ transparent and is not explained anywhere.

We'll improve the messaging in the ux to help the community understand just what this means and who has access to the data."

This bug tracks that.

Gerv
Blocks: 926644

Comment 1

4 years ago
Just changing the name from 'privileged' to 'staff' would make it a lot more transparent to me. I don't know whether you need to be more specific than that?
It's not equivalent to staff. This is a small group of people who have access to certain profile fields (for example, T-shirt size) that an individual might not choose to share with the entire directory. 

Privileged is not a fantastic name for it; suggestions welcome!
I think it would be helpful to also display the reason someone has privileged status for each person if we are going to publicize those people, should make it pretty clear.

Though right now nobody has this status, and it seems like it hasn't been needed, possibly because the UX for accessing this data in a large scale way is impractical right now. In fact, the operation of the privileged group seems bugged right now... (it breaks my profile if I add myself to that group via admin) so it's not even usable.
(Reporter)

Comment 4

4 years ago
If it's just about the t-shirts, why not call it "swagteam"? If not, what other fields are going to be visible only to this group?

Gerv
(In reply to Gervase Markham [:gerv] from comment #4)
> If it's just about the t-shirts, why not call it "swagteam"? If not, what
> other fields are going to be visible only to this group?
> 

As implied in comment 3, so far it's little more than a placeholder. 

When we initially conceived the privacy levels, we anticipated allowing users to set a variety of fields as privileged. Of the fields we have or I can imagine, I think "privileged" might be a valuable setting for account-type fields, clothing-type fields, location-type fields, and contribution metrics-type fields. The idea is that some fields might provide very useful information to a handful of folks -- your swag contact, your functional area lead, a People person, etc. -- and so you might want to populate them, but you might prefer not to publicize them. 

Obviously we haven't needed to use this much yet. T-shirt was the first field we added (for Summit 2013) that had this obvious "important to populate but not for sharing with the network" bit. :)
(Reporter)

Comment 6

4 years ago
(In reply to Justin Crawford [:hoosteeno] from comment #5)
> (In reply to Gervase Markham [:gerv] from comment #4)
> > If it's just about the t-shirts, why not call it "swagteam"? If not, what
> > other fields are going to be visible only to this group?
> > 
> 
> As implied in comment 3, so far it's little more than a placeholder. 
> 
> When we initially conceived the privacy levels, we anticipated allowing
> users to set a variety of fields as privileged. Of the fields we have or I
> can imagine, I think "privileged" might be a valuable setting for
> account-type fields, clothing-type fields, location-type fields, and
> contribution metrics-type fields.

But surely all of those would not be restricted to the same set of people that see t-shirt info?

I'm all for setting up field visibility, but we need to figure out how to do it without the groups and permissions system getting overly-complex.

As another example, I'm pretty sure we're going to need an "employee" level for things like internal phone numbers if we are ever going to obsolete the internal Mozilla phonebook (yay!). But I don't want to see the privacy chooser having 15 different entries to choose from.

Gerv
Depends on: 1011230
No longer blocks: 926644
Blocks: 1300758
You need to log in before you can comment on or make changes to this bug.