feature request: add team members to focus area pages

[cranmer]

Would be nice if a focus area page like this:
https://iris-hep.org/as.html

automatically listed the team members working in the area.

• either just names or also photos

[davidlange6]

I can do this, perhaps via pictures...I agree thats a good thing to have

[davidlange6]

is one approach I can propose (modulo fixing Mario's last name)

[henryiii]

I'd either let the photos crop, or align them at the bottom - it looks weird with different heights. We probably should pick an aspect ratio for team pictures. Otherwise looks nice. :)

[davidlange6]

I agree about the figures - not sure how to accomplish that - will figure it out:)

[henryiii]

This currently has two problems: focus areas with no projects don't show any users (and users not in a project get missed), and extra users get added by cross-focus-area projects with users that should only be in one of the multiple focus areas.

[henryiii]

The best solution would be to have users list focus areas in the data files, but that would take a bit of work to get setup for everyone.

[davidlange6]

Its not clear what you mean by "users get added by cross-focus-area projects? if they are cross focus area then they are in both focus areas.. Whats an example use case?

[davidlange6]

focus areas with out projects (well, maybe we shouldn't have those..) - indeed, having their own team list makes sense to me. This also addresses users without projects (again strange to me:) )

the downside of focus areas in the people data files is that we are then asking for this information to be maintained in two places.

[osg-cat]

@davidlange6, I brought up the issue with cross-area team listings. Just because area Foo includes project Bar doesn’t mean that the Foo area considers everyone who works on project Bar to be part of their team. It’s great to have projects that cross areas, of course, but I think that project membership is simply a distinct thing from area membership.

[davidlange6]

I’m not familiar with such a strict focus-area definition. I guess an osg specific issue? Ok. I’d personally prefer that we maintain exceptions rather than duplicating everything. Eg, focus area members are project members + a dedicated list of exceptions to add + a dedicated list of exceptions to omit in each focus area yml.

…

On May 5, 2021, at 3:37 PM, Tim Cartwright ***@***.***> wrote: @davidlange6, I brought up the issue with cross-area team listings. Just because area Foo includes project Bar doesn’t mean that the Foo area considers everyone who works on project Bar to be part of their team. It’s great to have projects that cross areas, of course, but I think that project membership is simply a distinct thing from area membership. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[osg-cat]

Sure, that’s fine.

[henryiii]

I prefer simplicity. A user can be asked to specify what focus areas they are in when they set up their profile (and that's already been added to the docs). Making a link focus-areas <-> projects doesn't work; some focus areas (ssc, blueprint, ssl) do not have projects. And as @osg-cat pointed out, cross-focus-area projects may not want all users in all focus areas. And I think users can keep track of what focus areas they consider themselves part of, while asking them to keep both an inclusion and exclusion list and understand why those are needed is much too complicated. Ah, you are thinking of a list being kept per focus area, that's better, but still I think this is something that a user can help with. Unlike projects, which are more focused in scope and generally have a maintainer, focus areas are very broad. Remembering to update the list when a new user comes in is likely much harder than forcing them to list focus-areas.

[henryiii]

(Reopend this until we decide what we want)

[henryiii]

The current implementation (people have focus areas) can ensure every user eventually gets a focus area very simply (already printed as warnings, can become an error once everyone has one), and the current version would be best for #716

[davidlange6]

Does the average newcomer understand “focus-area”s? Its not clear to me. Users know they are attached to a project - if there are politics behind what focus area they are in, likely they won’t know about them. If I’m wrong, then sure lets remove all the user info from projects and put that into the user ymls with also focus-areas listed (extending what you’ve done) fwiw- I don’t understand why ssc and ssl don’t have projects. (And blueprint is one person)

…

On May 5, 2021, at 7:12 PM, Henry Schreiner ***@***.***> wrote: I prefer simplicity. A user can be asked to specify what focus areas they are in when they set up their profile (and that's already been added to the docs). Making a link focus-areas <-> projects doesn't work; some focus areas (ssc, blueprint, ssl) do not have projects. And as @osg-cat pointed out, cross-focus-area projects may not want all users in all focus areas. And I think users can keep track of what focus areas they consider themselves part of, while asking them to keep both an inclusion and exclusion list and understand why those are needed is much too complicated. Ah, you are thinking of a list being kept per focus area, that's better, but still I think this is something that a user can help with. Unlike projects, which are more focused in scope and generally have a maintainer, focus areas are very broad. Remembering to update the list when a new user comes in is likely much harder than forcing them to list focus-areas. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[henryiii]

remove all the user info from projects and put that into the user ymls

This does not make sense. Projects can have non-IRIS-HEP members in them. Focus areas cannot have non-IRIS-HEP people. I don't think they can be combined like this.

Every user should be involved in at least one focus area (possibly requiring "core"). Not every user is involved in a project. So having a list of users for a project on the project page works (and projects are small enough that the head of the project should know all the members). But focus areas are broad - I don't know everyone in AS or IA. The focus areas are prominently listed on the website, and if there's a "no focus-area" error when making a new user PR, I think it's easy for us to query and find out what fa(s) a user is in.

Also, projects tend to be centrally managed, while focus areas are not really managed. For most projects, I can point at someone who knows everyone on the project and will add and remove people from the project, including the non-IRIS-HEP people. So that's why I think the two memberships should be different.

[davidlange6]

On May 5, 2021, at 7:36 PM, Henry Schreiner ***@***.***> wrote: remove all the user info from projects and put that into the user ymls This does not make sense. Projects can have non-IRIS-HEP members in them. Focus areas cannot have non-IRIS-HEP people. I don't think they can be combined like this. Every user should be involved in at least one focus area (possibly requiring "core"). Not every user is involved in a project.

I think differently - but the question is if things are project focused or focus area focused (eg, I know my focus area is very project focused, so a new person will know they are working on pvfinder but will need advise about what focus area. Probably this varies across the project

So having a list of users for a project (and projects are small enough that the head of the project should know all the members). But focus areas are broad - I don't know everyone in AS or IA. The focus areas are prominently listed on the website, and if there's a "no focus-area" error when making a new user PR, I think it's easy for us to query and find out what fa(s) a user is in. Also, projects tend to be centrally managed, while focus areas are not really managed. For most projects, I can point at someone who knows everyone on the project and will add and remove people from the project, including the non-IRIS-HEP people. So that's why I think the two memberships should be different.

Not so much in my experience.. Thinking more, what are the common workflows? 1) we have a new user —> everything in the user yml will be most reliable 2) we have a new project —> project oriented lists is most reliable 3) user changes from project a to b. —> user yml slightly more reliable (both likely to fail..) Item 1 is the most common so ought to be easiest to get right.