Update team membership docs and refactor

[choldgraf]

We recently discussed updating our team membership structure, and agreed that a good approach would be to remove the "team colors" and instead focus on team names that are more intuitive to understand:

• Rename "core team" to "JupyterHub council" #497

As I was trying to make those changes, I found it hard to update this information without also disentangling some of our other team compass docs. In that process I also noticed several other improvements that could be made to the team compass docs, and so I took the liberty of making some general refactoring improvements.

There are a lot of changes here so below is a quick guide to where to look for the most relevant parts:

Main change: team membership description

Updated the team structure page and our governance page to reflect the discussion in #497 . I haven't added people to one team or another yet, this PR is mostly about describing the teams themselves, their roles / responsibilities, etc.

Most relevant files to look at:

• Team structure page: https://github.com/jupyterhub/team-compass/pull/517/files#diff-47c689c025f0156a87bfa49baec525fa842fdbdcfac2a01a839c193eee473ef3
• Team governance page: https://github.com/jupyterhub/team-compass/pull/517/files#diff-12eee4855bccb58c299f99b7f7f614e1a0fc5345bf945b37e294a29b6ca212f8
• Team database: https://github.com/jupyterhub/team-compass/pull/517/files#diff-c78437436bac23f5dc0a802561fbf7c59678b475c3f2b51400b51bd1b42d0fef

Other cleanup:

Meetings

• Moved all of our meeting notes into a meetings/ top-level folder
• Consolidated our weekly meeting notes into a single markdown file (because having each as a separate page was really slowing down Sphinx builds)

Contributors page

• Moved our team data files into a _data/ folder to make it explicit that it isn't a "content page"
• Updated our contributors scripts to use sphinx-design so we have less hacky and custom CSS/HTML.

Consolidation / theme

• Moved some of our README content into links in our team compass, so that we have single sources of truth
• Moved the Binder governance page into a section of the JupyterHub governance page, so it's easier to read
• Generally tried to start moving pages underneath top-level folders so that it's easier to navigate and maintain
• Cleaned up some header / content bugs that were generating a lot of Sphinx warnings...I believe we no longer have any Sphinx warnings as a result!
• Added more theme options to trigger nicer social media / forum / etc linking behavior.

I am happy to iterate more on this PR, though I know it's a lot so let me know if anybody would like more specific explanation on a subset of changes etc.

• fixes Our list of previous meetings is broken #387
• ref Rename "core team" to "JupyterHub council" #497

[minrk]

I think this is really great, and looks like an excellent update to the structure. Very clear!

[consideRatio]

@choldgraf i saw you had added live command to the Makefile. I've added the command devenv to do the same in several other jupyterhub repos along with linkcheck. For consistency, is 320516e acceptable to you? I pushed it as a commit to this PR.

Some notes about the changes in that commit:

1. sphinx-quickstart generating these kinds of files has changed a bit over time, some changes reflect how it has evolved as well.
2. Ignoring _build explicitly doesn't seem to be needed
3. While I dislike having a make.bat at all if we don't keep it in sync with the Makefile, i think we in the jupyterhub team are quite stable with the commands we need in our docs/Makefile, so copy pasting a Makefile and a make.bat with devenv and linkcheck isn't much additional work.
4. We can easily also add a linkcheck test workflow like https://github.com/jupyterhub/zero-to-jupyterhub-k8s/blob/main/.github/workflows/test-docs.yaml alongside, but I can do that in another PR later.

[consideRatio]

This looks great, since this changes so many files, I suggest we go for a merge sooner rather than later to avoid conflicts etc. @choldgraf if you think the commit I pushed is acceptable, then +1 for also pressing merge!

[choldgraf]

I'm fine with using whatever makefile structure is it is a standard across our repositories!

Re: the make.bat, i agree with that too. Though personally I think it'd be nice if we used either tox or nox for these kinds of automation things, but that is outside the scope of this PR.

For merging quickly, as long as there are no objections I'm also good to go! We will need to iterate further as we learn more anyway

[consideRatio]

@choldgraf I'll go for a merge here then! I'm thinking that its sufficient for a merge at this point now that this has been open for 8 days and have been reviewed and approved by two others, at least because its mainly some refactoring beyond the already agreed upon change.

[consideRatio]

Though personally I think it'd be nice if we used either tox or nox for these kinds of automation things, but that is outside the scope of this PR.

This is certainly a subjective aspect, but I'm quite opinionated against making a change away from the use of docs/Makefile (specifically about how we build our docs etc).

1. I've not learned about tox or nox, so it would be another tool to learn about, which can be fine of course.
2. doit was a tool discussed as alternative for make in jupyter/docker-stacks. I worry about opening up lengthy discussions on what tool to use or switching tools over time and how that could create a flora of tools in use instead of a single tool like we now have.
3. make was available in TravisCI, and is available in CircleCI and GitHub actions without any installations needed, maybe it is available by default in linux/mac computers? If the tool to replace make isn't available by default in most environments, that adds complexity and more things to document etc.
4. make is a very robust tool at this point and I've never experienced a need to consider what version of make is used etc because perhaps there is a bug in make itself.
5. We have so few commands in our Makefiles, so it seems like we may not need something more advanced anyhow.

[choldgraf]

I definitely don't have as strong of opinions about make vs. things like tox and nox, but the way I look at it is that the complexity of learning tox or nox (which from a user's perspective would just be pip install nox and then nox -s <command> instead of make <command>) is not as great as the complexity of managing your own local virtual environments, which I still haven't managed to figure out myself, and without that I often run into errors in version conflicts etc when working with non-trivial docs builds. Anyway, we can take that conversation to another space

[consideRatio]

@choldgraf ah it's about the virtual environment part, i thought it was only about "run commands" part. I guess nox + makefile can be used as well then, where tox nox etc could be part of the setup of the python environment. The current Makefile for our docs doesn't do anything related to setup of the environment, it is expected you have done pip install -r requirements.txt ahead of time in our repos, in some python environment.

[choldgraf]

yeah the nice thing about tox or nox is that they come bundled with isolated environments. So the first time you run tox -e docs (for example), it first runs the installation commands for the environment and automatically puts it in a .tox/docs folder. That way you never need to worry about having the right environment installed