Name initial core team and add documentation about roles

[Zsailer]

Follow up to #5.

Names the core team based on responses from #5. Adds a set of MyST pages and config for rendering via readthedocs.

The pages define the responsibilities and privileges of a team member. This is almost entirely borrowed from the JupyterHub/Binder Team Compass repo.

[blink1073]

Thank you!

[vidartf]

Was the .DS_store meant to be committed?

[Zsailer]

I've removed myself from "Lead" to Red Team for this PR. I think it's most appropriate to nominate a Team Lead in its own PR and merge it after the initial team is formed. We can do this early in the new year.

This PR should be ready for final review.

[kevin-bates]

The built output looks great @Zsailer - thank you!

[lresende]

I know you are trying to follow the JupyterHub notion of team colors, but I would like to really ask yourself if this would introduce a barrier to growing the community. Most open-source projects today have a notion of committers/maintainers and core maintainers/PMC (or emeritus) which works without the need of a legend, which is not true for the "group colors". I also think the membership is based on trust, and we should not distinguish between red and blue teams, basically, you move a step on the latter based on your contributions, being those code or non-code... but I wouldn't argue about that.

Another issue is that, with the new governance, we are moving away from BDFL favoring consensus building with a process to reconcile disagreements via vote, and we should really avoid naming a team leader which implies that that person has a different level of power among the community members.

[lresende]

Also, if the folks are planning to move Jupyter Enterprise Gateway to this org, I would consider adding @lresende and @kevin-bates as core-committers.

[echarles]

Most open-source projects today have a notion of committers/maintainers and core maintainers/PMC (or emeritus) which works without the need of a legend, which is not true for the "group colors". I also think the membership is based on trust, and we should not distinguish between red and blue teams, basically, you move a step on the latter based on your contributions, being those code or non-code... but I wouldn't argue about that.

I agree with @lresende that I need the legend to make sense of the colors, and that I would feel more comfortable with Contributor/Committer/PMC/Chair/Emeritus status as I have been used when being a active Apache committer (https://people.apache.org/committer-index.html, maybe also influencing @lresende as being also a Apache committer).

This is a discussion that can anyway occur in the future in relationship what the other Jupyter projects are doing, and based on Board inputs, so for the sake of moving forward the team setup, I want to approve this PR, but will wait a bit to ensure @lresende is added to the Team.

Thx All!

[Zsailer]

Thank you for your feedback, @lresende and @echarles!

I broke up my response into two separate decisions to make:

1. Committer/PMC/Emeritus model vs. Red/Blue/Green model
2. Eliminate Team Lead Role (keep SSC representative role, of course)

Committer/PMC/Emeritus model vs. Red/Blue/Green model

Most open-source projects today have a notion of committers/maintainers and core maintainers/PMC (or emeritus) which works without the need of a legend, which is not true for the "group colors".

I think you're right. I think this terminology might be more broadly familiar in open-source. I'm happy to drop the team colors in favor of the committer, PMC, emeritus language if others agree..

this would introduce a barrier to growing the community

I'm not sure that I agree that this model introduces more of a barrier than the Apache model, except that people might be less familiar with the colors' meanings.

I think the intentions behind the Red/Blue/Green model from JupyterHub is that it encouraged a broader contributor community by recognizing non-code contributors as team members (with write access). In my experience the committer/PMC/emeritus model tends to select mostly for code contributors only.

we should not distinguish between red and blue teams, basically, you move a step on the latter based on your contributions, being those code or non-code... but I wouldn't argue about that.

Hm, isn't this similar to distinguishing between committer and PMC in Apache's model? I think the Blue -> Red transition is less restrictive, because it doesn't require a nomination from other Red members; rather you just re-label yourself based on your contributions. In Apache's model, you need to be nominated for committer, then nominated again, later, for PMC.

It's possible we are just discussing semantics here, but I think it's worth discussing.

Eliminate Team Lead Role

consensus building with a process to reconcile disagreements via vote, and we should really avoid naming a team leader which implies that that person has a different level of power among the community members.

This is a fantastic point, and I wholeheartedly agree. You'll see in #5 that I conflated the Software Steering Council (SSC) representative with the Team Lead role, and that was a mistake on my part.

I propose that we drop the notion of "Team Lead" altogether and just have a nominated SSC representative role. They don't have any decision making power; rather, they represent the Jupyter Server subproject in an SSC vote.

[Zsailer]

@lresende, I've added you to the team 😎.

[Zsailer]

We discussed this PR quite a bit in the Jupyter Server meeting today. I will be making several changes based on that conversation:

• Absolve the team lead position
• Eliminate the team colors.
• Define two categories of team members, "active" and "not currently active". Active team members have voting rights and not active members do not.
• Add description of SSC Representative to docs.

[Zsailer]

As a result, everyone who asked to be a red+blue team member will be added to the active list. Green members will be added to the "not currently active" list.

[Zsailer]

Okay, I've rewritten the docs quite extensively based on the feedback from today. Please feel free to review and leave feedback.

I've also changed the team to use Sphinx Book Theme, since that seems better for this type of documentation.

We can leave this PR open for one more week and merge it at next week's meeting. Thank you all for a super helpful discussion.

[JasonWeill]

A shared calendar (e.g., on Google Calendar) might make it easier for people to see, at a glance, when team members are unavailable. Grant all team members permissions to add their own events to the calendar. At a previous company, our team used one for this purpose.

[kevin-bates]

Is this implying that the team member will be transitioning to 'inactive'? Or just indicating they'll be away for a bit but intend to remain 'active'. Opening an issue to indicate they won't be at the next meeting or two (or very active in the org for a couple of weeks) seems a little heavyweight. I like @jweill-aws's suggestion of an internal calendar - available only to team members - for this purpose.

[echarles]

I have read a few durations (3 weeks, 1 year) regarding the expected period to declare being inactive. On my side, I'd prefer not having to ping-pong between active and inactive based on my schedule. I'd also prefer not to add yet another calendar to maintain. My previous experience at Apache is that once you get committer role, you get it for life, whatever happens. A committer can retire him self if he wants. The exception is the Apache membership where you are expected to participate to the yearly vote.

For here, I would prefer that we say to bump to inactive for year order of magnitude inactivity.

[Zsailer]

Let's drop the part where we say to open an issue. I agree, this is heavy handed. This can happen informally.

Really the goal here is to relieve a team member from feeling pressured to watch this repo for any formal votes that arise while they are out on leave/vacation etc.

[mwakaba2]

what would be considered a long leave or vacation? It might help to state the duration or some kind of minimum threshold. (e.g. anything longer than 2 or 3 weeks)

[Zsailer]

Good question. Really, this is just a way for a team-member to say they wouldn't be available for any votes that arise during the period they are away.

Since voting cycles are about 2 weeks long (based on Jupyter governance), 2 weeks is probably an appropriate duration to use here.

I'm not sure we need to be this technical, but perhaps this would be a good guide.

[mwakaba2]

looks great @Zsailer ! Thank you for putting this together!
I just had one question around what's considered a long leave or vacation.

[kevin-bates]

Mostly nits. I also agree with previous comments.

[kevin-bates]

Is this implying that the team member will be transitioning to 'inactive'? Or just indicating they'll be away for a bit but intend to remain 'active'. Opening an issue to indicate they won't be at the next meeting or two (or very active in the org for a couple of weeks) seems a little heavyweight. I like @jweill-aws's suggestion of an internal calendar - available only to team members - for this purpose.