Consider using the kent dodds "all-contributors" spec for listing our team

[choldgraf]

Another project I'm involved with uses the following specification to list and give credit to contributors: https://github.com/kentcdodds/all-contributors

I think something like this might be good for the JupyterHub / Binder teams, since a lot of the work is non-coding in nature. What do folks think about using something like this instead of the current lists in the team-compass repo? cc @willingc as I believe she suggested at the meeting we should find ways to recognize non-code contributions!

[betatim]

I like the gallery aspect compared to just a list of names. Makes you realise that contributors are also just humans :)

Having functions/areas/task types associated to each contributor makes me uneasy. I think you either do work that qualifies you as a contributor or you don't. Assigning labels makes me think there is some judgement/ranking/gotta collect them all to this. This probably comes from my "upbringing" in HEP where membership of a research collaboration is not qualified. You are either in or out, but there is no attempt to distinguish between "this person is on call all the time" or "authors papers like crazy" or "trains all the best deep learning models". To operate a large experiment over a long time requires a lot of different skills and types of people so trying to assign any kind of ranking to different kinds of contributions seems like a bad thing to do for the social dynamics.

[choldgraf]

@betatim that makes sense, do you have any other suggestions for how to recognize the non-coding contributions of team-members? I definitely don't want something like this to become a competition, just trying to be a bit more explicit about how people are contributing to the project. E.g. I noticed that most of the non-coding people on the README didn't list their actual role within the group, I suspect partially because non-coding roles aren't always easy to define / communicate.

[betatim]

E.g. I noticed that most of the non-coding people on the README didn't list their actual role within the group, I suspect partially because non-coding roles aren't always easy to define / communicate.

Nods, this is why I thought maybe we just get rid of roles and have it as a binary "this person is a contributor" list. Especially because we have people for who the best label would be "helps out where help is needed, no matter what it is".

Asked differently: what purpose do the labels serve?

[willingc]

I think that without the emojis that people may assume that all the contributors are code contributors.

I would simplify the emojis by not allowing links and have a max of 3 emojis. If you hit 3, pick your favorites. The emojis can be what you have done or what you enjoy doing and would do for the project.

[ellisonbg]

Listing non code contributors and contributions is really important. In lab, we ask each person listed to self describe their role in the project - and provide help to them brainstorming on those. We have found that roles are often subtle so I would be hesitant to box people into categories

Sent from my iPhone

On Jun 6, 2018, at 6:11 AM, Carol Willing notifications@github.com wrote:

I think that without the emojis that people may assume that all the contributors are code contributors.

I would simplify the emojis by not allowing links and have a max of 3 emojis. If you hit 3, pick your favorites. The emojis can be what you have done or what you enjoy doing and would do for the project.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[ellisonbg]

Another purpose the listed roles serve - without them external people who want to talk to someone will always contact the most senior coder - often by commits. That puts a large load on that person and they often aren’t the right person to talk to. The listed roles help people to know whom to talk to about what.

Sent from my iPhone

On Jun 6, 2018, at 6:11 AM, Carol Willing notifications@github.com wrote:

I think that without the emojis that people may assume that all the contributors are code contributors.

I would simplify the emojis by not allowing links and have a max of 3 emojis. If you hit 3, pick your favorites. The emojis can be what you have done or what you enjoy doing and would do for the project.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[betatim]

Sounds reasonable! Especially if the experience is that people approach contributors personally/outside of the issues. Slightly OT but should we add a sentence to the READMEs of the various Binder repos encouraging people to post an issue or ask the gitter channel instead of talking directly to individual contributors? Something like "Please post your questions as an issue or ask on the public gitter channel. You are more likely to get a fast response that way and help grow the knowledge of the community compared to approaching individual contributors in private."

[choldgraf]

I'm +1 on either @willingc 's idea of capping it to 3 emojis, or making sure that we put team effort into guiding people to self-describe their role in a way that is satisfying to them.

[jzf2101]

What are next steps on this?

[choldgraf]

A next step could be someone making a PR that "codifies" one of the practices we described above, maybe simply by adding a short guide to the team-compass repo along w/ instructions to people about adding their names.

[choldgraf]

we now have this on the [team compass team page!](As this is now codified in the team compass website

[ellisonbg]

Re-opening for further discussion. One of my initial hesitations about a purely emoji based approach (I have no idea what the emojis mean), was alleviated by the fact that on the demo site, there are tooltips that show on hover with a descriptive text about what that emoji is. However, on the JupyterHub site, those tooltips are missing, so it is really difficult to know what they mean.

My other hesitation is that the set of emojis is limited in a way that doesn't capture the complex reality of how different people contribute. An example is that the Design emoji and description are only for visual design, which is a very small part of design overall. When I look at how the team contributions are described for JupyterLab (https://github.com/jupyterlab/jupyterlab#team), there are a lot of things that don't have emojis (co-creator, backend, frontend, UX design, vision, operations, architecture, etc.).

I want to be clear that I am strongly in favor of encouraging and acknowledging a wide range of different types of contributions to our projects - I guess I feel this approach doesn't go far enough.

[choldgraf]

I'd love to think about ways that we can improve the signaling around the emojis. I agree that in their current form they aren't super clear what they are conveying. One thing we could do is programmatically create a layout similar to what the all-contributors repo uses here:

https://github.com/kentcdodds/all-contributors#contributors

[willingc]

@choldgraf @ellisonbg I've opted for words over emojis.

[ellisonbg]

Another way to improve the emoji experience is to include-above the table on our site-a legend that maps from the emojis to words. This would also enable us to add new emojis/topics beyond those in Kent Dodds.

However, I am still probably biased towards the power of words for this usage case.

Sent from my iPhone

On Oct 28, 2018, at 9:27 AM, Carol Willing notifications@github.com wrote:

@choldgraf @ellisonbg I've opted for words over emojis.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[choldgraf]

I'd also be open to replacing the emojis with words, however I'd like there to be some structure that facilitates this process. In looking at the earlier version of the "team" page, it felt like the words used to describe people's roles weren't always clear (and in many cases were just missing). If folks don't think that emojis get us closer to making it easier for people to identify the specifics of what they help with, then I'm also open to talking about other systems!

[ellisonbg]

I do think that emojis are nice in that the exist before a particular contributor adds their information as a contributor, so they can see exactly what types of things constitute a contribution (it isn't obvious as you mention).

On Sun, Oct 28, 2018 at 11:20 AM Chris Holdgraf notifications@github.com wrote:

I'd also be open to replacing the emojis with words, however I'd like there to be some structure that facilitates this process. In looking at the earlier version of the "team" page, it felt like the words used to describe people's roles weren't always clear (and in many cases were just missing). If folks don't think that emojis get us closer to making it easier for people to identify the specifics of what they help with, then I'm also open to talking about other systems!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jupyterhub/team-compass/issues/41#issuecomment-433728830, or mute the thread https://github.com/notifications/unsubscribe-auth/AABr0OKO_4tBow3JraIasFHhkXC7rzC7ks5upfWLgaJpZM4UayrH .

-- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com

[choldgraf]

closing this as we do this now!