`_.
54 |
--------------------------------------------------------------------------------
/docs/make.bat:
--------------------------------------------------------------------------------
1 | @ECHO OFF
2 |
3 | pushd %~dp0
4 |
5 | REM Command file for Sphinx documentation
6 |
7 | if "%SPHINXBUILD%" == "" (
8 | set SPHINXBUILD=python -msphinx
9 | )
10 | set SOURCEDIR=.
11 | set BUILDDIR=_build
12 | set SPHINXPROJ=TeamCompass
13 |
14 | if "%1" == "" goto help
15 |
16 | %SPHINXBUILD% >NUL 2>NUL
17 | if errorlevel 9009 (
18 | echo.
19 | echo.The Sphinx module was not found. Make sure you have Sphinx installed,
20 | echo.then set the SPHINXBUILD environment variable to point to the full
21 | echo.path of the 'sphinx-build' executable. Alternatively you may add the
22 | echo.Sphinx directory to PATH.
23 | echo.
24 | echo.If you don't have Sphinx installed, grab it from
25 | echo.http://sphinx-doc.org/
26 | exit /b 1
27 | )
28 |
29 | %SPHINXBUILD% -M %1 %SOURCEDIR% %BUILDDIR% %SPHINXOPTS%
30 | goto end
31 |
32 | :help
33 | %SPHINXBUILD% -M help %SOURCEDIR% %BUILDDIR% %SPHINXOPTS%
34 |
35 | :end
36 | popd
37 |
--------------------------------------------------------------------------------
/docs/requirements.txt:
--------------------------------------------------------------------------------
1 | sphinx>=3
2 | sphinx_copybutton
3 | sphinx_book_theme
4 | pandas
5 | ruamel.yaml
6 | myst_parser
7 |
--------------------------------------------------------------------------------
/docs/scripts/gen_contributors.py:
--------------------------------------------------------------------------------
1 | """Generate HTML Contributors tables for team pages
2 | """
3 | import pathlib
4 | import pandas as pd
5 | import os
6 | import os.path as op
7 | from ruamel import yaml
8 |
9 | # Variables
10 | N_PER_ROW = 4
11 |
12 | # Init
13 | path_data = op.join(op.dirname(op.abspath(__file__)), "..", "team")
14 | yaml = yaml.YAML()
15 |
16 | template = '
{NAME} {AFFILIATION} '
17 |
18 |
19 | def _generate_contributors(contributors):
20 | """Generate an HTML list of contributors, given a dataframe of their information."""
21 | s = ['', '']
22 | for ix, person in contributors.iterrows():
23 | if ix % N_PER_ROW == 0 and ix != 0:
24 | s += [' ']
25 |
26 | # Find user gravatar url
27 | avatar_url = "https://github.com/{HANDLE}.png?size=200".format(
28 | HANDLE=person["handle"].lstrip("@")
29 | )
30 |
31 | # Add user
32 | format_dict = dict(
33 | HANDLE=person["handle"],
34 | HANDLE_URL="https://github.com/{HANDLE}".format(
35 | HANDLE=person["handle"].lstrip("@")
36 | ),
37 | AFFILIATION=person["affiliation"],
38 | AVATAR_URL=avatar_url,
39 | NAME=person["name"],
40 | )
41 |
42 | # Render
43 | s += [template.format(**format_dict)]
44 | s += [" "]
45 | final_text = [".. raw:: html", ""]
46 | for line in s:
47 | final_text += [" " + line]
48 | final_text = "\n".join(final_text)
49 | return final_text
50 |
51 | # Load contributor list
52 | source_dir = pathlib.Path(path_data)
53 | contributor_file = source_dir / "contributors-jupyter-server.yaml"
54 | with open(contributor_file, "r") as ff:
55 | data = yaml.load(ff)
56 |
57 | people = pd.DataFrame(data)
58 |
59 | # Create active member table
60 | active_people = people[people.team == "active"]
61 | table = _generate_contributors(active_people)
62 | with open(source_dir / "active.txt", "w") as ff:
63 | ff.write(table)
64 |
65 | # Create inactive member table
66 | inactive_people = people[people.team == "inactive"]
67 | table = _generate_contributors(inactive_people)
68 | with open(source_dir / "inactive.txt", "w") as ff:
69 | ff.write(table)
70 |
71 | # Find past and current SSC representatives
72 | ssc_reps = people[people.ssc.notna()]
73 | for index, rep in ssc_reps.iterrows():
74 | # Fetch the latest term
75 | latest_term = rep.ssc[-1]
76 | # Split date and check if there is an end date.
77 | is_current = latest_term.split("-")[-1] == ""
78 | if is_current:
79 | break
80 |
81 | table = _generate_contributors(rep.to_frame().T)
82 | with open(source_dir / "ssc-current.txt", "w") as ff:
83 | ff.write(table)
84 |
85 | table = _generate_contributors(ssc_reps.drop(index))
86 | with open(source_dir / "ssc-past.txt", "w") as ff:
87 | ff.write(table)
88 |
--------------------------------------------------------------------------------
/docs/team.md:
--------------------------------------------------------------------------------
1 | # Current team members
2 |
3 | This page lists (alphabetically) the officially named Jupyter Server Team.
4 |
5 | ## Active members
6 |
7 | Active team members are actively participating in the development, maintenance, planning, and discussion around projects in the Jupyter Server Github organization.
8 |
9 | ```{eval-rst}
10 |
11 | .. include:: team/active.txt
12 |
13 | ```
14 |
15 | ## Inactive members
16 |
17 | Inactive team members are (temporarily or not) pausing their active participation in the Jupyter Server community. They can reactivate themselves at any point in the future; it does not require a nomination by a current active member.
18 |
19 | ```{eval-rst}
20 |
21 | .. include:: team/inactive.txt
22 |
23 | ```
24 |
25 | ## Software Steering Council (SSC) Representative
26 |
27 | Each *official* subproject in Jupyter gets a single [Software Steering Council representative](https://jupyter.org/governance/software_steering_council.html#software-steering-council). Jupyter Server's representative is elected by the active team members. In the Jupyter Server subproject, our representative is elected to a one-year term.
28 |
29 | Current SSC Representative:
30 |
31 | ```{eval-rst}
32 |
33 | .. include:: team/ssc-current.txt
34 |
35 | ```
36 |
37 |
38 | Previous SSC representatives:
39 |
40 | ```{eval-rst}
41 |
42 | .. include:: team/ssc-past.txt
43 |
44 | ```
45 |
--------------------------------------------------------------------------------
/docs/team/becoming-member.md:
--------------------------------------------------------------------------------
1 | # Becoming a team member
2 |
3 | ## Team member responsibilities
4 |
5 | Active team members actively carry out the responsibilities listed in the [Membership Guide Page](membership_guidelines).
6 |
7 | ## Active and inactive membership
8 |
9 | There are two types of team members, **active** and **inactive**.
10 |
11 | Active members:
12 |
13 | * Must be nominated by a current team member.
14 | * Can be elected as the Software Steering Council representative for Jupyter Server.
15 | * Get a vote in a voting situation.
16 | * Count towards quorum in a voting situation.
17 | * Are expected to participate in a majority of the team votes.
18 | * Can nominate new team members.
19 | * Should actively participate, either synchronously or asynchronously, in team meetings.
20 |
21 | Inactive members:
22 |
23 | * Were previously an active team member.
24 | * Do not vote.
25 | * Are not counted towards voting quorum.
26 | * Can "reactivate" at any time by expressing their change in status publicly.
27 |
28 | Team members can freely pass between active and inactive at any time. They *should* publicly state their status change in a pull request that updates the `contributors-jupyter-server.yaml` file with their status change.
29 |
30 | This means an inactive team member can "reactivate" themselves at any time by publicly stating their change in status. This does not require a nomination from another team member.
31 |
32 | For example, a team member who is going out on a long leave/vacation (>2 weeks) can temporarily move to the inactive team during their absence and immediately reactivate upon return. This isn't required, but this can relieve them from having to watch this repository for any formal votes that happen during their absence.
33 |
34 | ## Nominating a new member
35 |
36 | For someone to become a team member, they should already be a consistent,
37 | positive, productive member of the community. Newcomers are encouraged to
38 | become team members after they've shown a sustained interest in
39 | engaging with the community. Moreover, team members should be interested in
40 | **continuing their engagement** over a long-ish period of time (at least one year), generally
41 | putting in more time and effort than non-team members. This doesn't have to
42 | mean contributing code - it can be assisting others in forums/issues, reviewing
43 | pull requests, participating in team meetings, etc.
44 |
45 | Any new team members must be nominated and championed by an active team member.
46 | This process takes the following steps:
47 |
48 | 1. The champion should first discuss internally with team members to
49 | ensure that there's general consensus before officially starting
50 | the process.
51 | 2. If there seems to be team consensus,
52 | the champion contacts the potential new team member and asks if they are
53 | interested. Don't forget to run them by the {ref}`membership_guidelines`
54 | page to make sure they understand what they're signing up for.
55 | If so, then move to the next step.
56 | 3. The champion opens a new issue in the [team compass repository](https://github.com/jupyter-server/team-compass>).
57 | The issue should state your support of the new team member, discuss why
58 | you think they are great and why they should join the team.
59 | 4. This issue should stay open for around 7 days to give members of the team
60 | a chance to weigh in their thoughts (and support!).
61 | 5. If there are no objections that haven't been resolved, the new team member
62 | is welcomed into the community as an official team member!
63 |
64 | ## Membership Maintenance
65 |
66 | Every six months, one currently active member should open an issue in the team-compass repo asking all currently active team members to reply if they still consider themselves active. If not (or no response is given by a team member), it will be assumed that they have gone inactive. This will help keep the active team up-to-date.
67 |
68 | Remember, an inactive member can return at any time by simply changing their status on the team-compass page.
69 |
--------------------------------------------------------------------------------
/docs/team/contributors-jupyter-server.yaml:
--------------------------------------------------------------------------------
1 | # Active Team members
2 | # Use ALPHABETICAL (BY LAST NAME) ORDER please :-)
3 |
4 | - name: Damian Avila
5 | handle: "@damianavila"
6 | affiliation: UMSI and 2i2c
7 | team: active
8 | last-check-in: 2024-01
9 |
10 | - name: David Brochart
11 | handle: "@davidbrochart"
12 | affiliation: Quantstack
13 | team: active
14 | last-check-in: 2024-01
15 |
16 | - name: Sylvain Corlay
17 | handle: "@SylvainCorlay"
18 | affiliation: QuantStack
19 | team: active
20 | last-check-in: 2024-01
21 |
22 | - name: Afshin Darian
23 | handle: "@afshin"
24 | affiliation: QuantStack
25 | team: active
26 | last-check-in: 2024-01
27 |
28 | - name: Vidar Fauske
29 | handle: "@vidartf"
30 | affiliation: J.P. Morgan Chase
31 | team: active
32 | last-check-in: 2024-01
33 | ssc:
34 | - 2024/04-
35 |
36 | - name: Brian Granger
37 | handle: "@ellisonbg"
38 | affiliation: Amazon Web Services
39 | team: active
40 | last-check-in: 2024-01
41 |
42 | - name: Paul Ivanov
43 | handle: "@ivanov"
44 | affiliation: Noteable
45 | team: active
46 | last-check-in: 2024-01
47 |
48 | - name: Piyush Jain
49 | handle: "@3coins"
50 | affiliation: Amazon Web Services
51 | team: active
52 | last-check-in: 2024-01
53 |
54 | - name: Luciano Resende
55 | handle: "@lresende"
56 | affiliation: Apple
57 | team: active
58 | last-check-in: 2024-01
59 |
60 | - name: Zach Sailer
61 | handle: "@Zsailer"
62 | affiliation: Apple
63 | team: active
64 | last-check-in: 2024-01
65 | ssc:
66 | - 2023/01-2024/04
67 |
68 | - name: Carol Willing
69 | handle: "@willingc"
70 | affiliation: Noteable
71 | team: active
72 | last-check-in: 2024-01
73 |
74 | # Inactive team members at the end, also alphabetical
75 | - name: Kevin Bates
76 | handle: "@kevin-bates"
77 | affiliation: Veritone
78 | team: inactive
79 | last-check-in: 2024-04
80 |
81 | - name: Jeremy Tuloup
82 | handle: "@jtpio"
83 | affiliation: Quantstack
84 | team: inactive
85 | last-check-in: 2024-01
86 |
87 | - name: Mariko Wakabayashi
88 | handle: "@mwakaba2"
89 | affiliation: OpenZeppelin
90 | team: inactive
91 | last-check-in: 2024-01
92 |
93 | - name: Jessica Xu
94 | handle: "@jess-x"
95 | affiliation: Cal Poly
96 | team: inactive
97 | last-check-in: 2024-01
98 |
99 | - name: Rahul Goyal
100 | handle: "@rahul26goyal"
101 | affiliation: Amazon Web Services
102 | team: inactive
103 | last-check-in: 2024-01
104 |
--------------------------------------------------------------------------------
/docs/team/decision-making.md:
--------------------------------------------------------------------------------
1 | # How decisions are made
2 |
3 | The Jupyter Server team follows the ["Decision Making" Guidelines](https://jupyter.org/governance/decision_making.html#required-aspects-of-decision-making) described in the main Jupyter governance documents.
4 |
5 | In short, we'll first seek an informal consensus. If a clear consensus cannot be reached, an active team member can call for a vote. The voting process then follows the guidelines laid out by the [Jupyter Governance model]((https://jupyter.org/governance/decision_making.html#required-aspects-of-decision-making)).
6 |
7 | ## Team size
8 |
9 | There is no limit to the size of the team. We follow the [guidelines laid out](https://jupyter.org/governance/bootstrapping_decision_making.html#bootstrapping-decision-making-bodies) by the broader Jupyter governance model which encourages a large, highly participatory decision body:
10 |
11 | > The new governance model and decision-making guide is designed to support large, highly participatory decision-making bodies. As such, even Subprojects that have a clear decision-making body today may wish to increase the size of that body to include more contributors.
12 |
--------------------------------------------------------------------------------
/docs/team/member-guide.md:
--------------------------------------------------------------------------------
1 | (membership_guidelines)=
2 |
3 | # Membership guidelines
4 |
5 | This page holds resources for members of the Jupyter Server team.
6 | They're meant to guide team members to be happy, productive members of the
7 | team!
8 |
9 | ## What are the team resources?
10 |
11 | There are a few resources that are particularly useful for team members. Here's
12 | a quick list to get you started.
13 |
14 | * [**The Jupyter Server Team Compass**](https://github.com/jupyter-server/team-compass)
15 | is a repository with lots of information about team-related things. It has
16 | development tips, information about team meetings, milestones and roadmaps,
17 | etc.
18 | * [**The Jupyter Server Team Compass issues**](https://github.com/jupyter-server/team-compass/issues)
19 | are where we often discuss specific, actionable things related to the *team*
20 | (e.g., discussing whether to change something in the team-compass repo).
21 | * [**The Jupyter Server gitter channel**](https://gitter.im/jupyter/jupyter_server) is used to have synchronous conversation
22 | for several projects. If a conversation will likely span multiple hours,
23 | or is relevant to many people, consider opening a thread in Discourse or
24 | the `team-compass` repository instead.
25 |
26 | ### General policy about communication channels
27 |
28 | We are trying to organize our discussions in order to help both contributors and
29 | maintainers find and choose the right communication channels and have a positive experience.
30 |
31 | In this respect, we are using:
32 | 1. GitHub issues for specific discussions related to changing a repository's content
33 | (e.g. feature requests, bug reports).
34 | 2. The [Discourse forum](http://discourse.jupyter.org/) for general discussions, support
35 | questions, or just as a place where we can inspire each other.
36 |
37 | ## How can I help?
38 |
39 | As a member of the team, you are encouraged to continue
40 | helping in the same ways that you already have. Your contributions to
41 | documentation, code, etc are always welcome.
42 |
43 | Don't forget that, as a member of the team, you're representing the community
44 | when you interact with people (online and offline). Try to keep a friendly, positive
45 | attitude, and be welcoming and helpful in bringing others into the community
46 | and answering their questions.
47 |
48 | ### Are there any specific responsibilies?
49 |
50 | We don't want team membership to
51 | be a big burden (many of us have one or more other jobs too!) but there are
52 | a few things that you should do as a new team member:
53 |
54 | 1. **"Watch" the [team compass repository](https://github.com/jupyter-server/team-compass)**
55 | so that you're notified when team conversations are happening.
56 | 2. **Stay up-to-date on team meetings**. You can find a notes from previous meetings pinned at
57 | the [top of the team-compass issues page](https://github.com/jupyter-server/team-compass/issues).
58 | 3. **Vote**. Participate in at least 2/3 of votes happening in the team-compass repo. You should be automatically pinged on Github when a vote is called.
59 | 4. **Let us know if you'll be unavailable** or out of town for an extended period
60 | of time. It's no problem if you need to focus on other things for a bit, but it's
61 | helpful for the team to know who will be around.
62 | If it's something you'd rather not mention to the public then
63 | send an email to one of the team members letting them know, and they
64 | can communicate it to the others.
65 | 5. **Foster open and inclusive discussion**. As a team member, you are
66 | responsible for ensuring that conversation in our communities is positive
67 | and inclusive. Open public issues to discuss things with the team. Try to
68 | do most communication in public spaces where others can join, or
69 | report back to team members if important conversations happened offline.
70 | When creating issues, provide enough context so that others can understand
71 | and provide their input. Encourage feedback and input from others
72 | often, and be patient when merging code - it is almost better to
73 | wait a bit for an approval than to self-merge.
74 |
75 | ## When should I merge a pull request?
76 |
77 | As a team member, you're encouraged to help others contribute to the project
78 | by reviewing their code, guiding them towards making a contribution and
79 | improving it, and ultimately merging their contribution into the project.
80 |
81 | Having merge rights is both a privilege and a responsibility - please be
82 | thoughtful when using it! To that extent, here are a few guidelines when
83 | deciding to merge things into one of our repositories:
84 |
85 | * **Use your best judgment**. As a member of the Jupyter Server team, we trust
86 | your judgment, and we ask you to use your best judgment in deciding when to
87 | take an action.
88 | * **Make sure it's quality code**. We know this is somewhat subjective, but
89 | ensure that the code is well-organized and thoughtfully-written, that any
90 | new features are documented, and that it abides by best-practices in Python,
91 | JavaScript, etc.
92 | * **Make sure there are tests**. We try not to merge any new features (or
93 | bugfixes!) without adding tests for them. It's easy to consider something
94 | minor-enough that it doesn't warrant a test, but try to avoid doing this!
95 | Adding tests usually only takes a moment, and our future selves will thank
96 | us for it later.
97 | * **Make sure there's been enough time for discussion**. We're an open
98 | community with an inclusive decision-making process. This means that
99 | sometimes we need to slow down to make sure others have a chance to
100 | review and provide their thoughts on changes. There's no hard rule for
101 | this, but try to make sure people have a chance to weigh in. Consider
102 | pinging people that you think might be interested in a question, and
103 | give it a few extra days before merging if you think a topic will be
104 | complex enough to warrant discussion.
105 | * **Don't be afraid to merge!** We know this is a bit counter-intuitive
106 | given what we just said, but don't be afraid to merge new code. If you
107 | think a change is really complex or potentially controversial, give it
108 | some time, but for most changes it is fine to just go ahead and merge.
109 | Again, we trust your judgment, and we don't want these guidelines to become
110 | a burden that slows down development.
111 |
--------------------------------------------------------------------------------
/readthedocs.yml:
--------------------------------------------------------------------------------
1 | # Read the Docs configuration file for Sphinx projects
2 | # See https://docs.readthedocs.io/en/stable/config-file/v2.html for details
3 |
4 | # Required
5 | version: 2
6 |
7 | # Set the OS, Python version and other tools you might need
8 | build:
9 | os: ubuntu-22.04
10 | tools:
11 | python: "3.12"
12 | # You can also specify other tool versions:
13 | # nodejs: "20"
14 | # rust: "1.70"
15 | # golang: "1.20"
16 |
17 | # Build documentation in the "docs/" directory with Sphinx
18 | sphinx:
19 | configuration: docs/conf.py
20 |
21 | # Optional but recommended, declare the Python requirements required
22 | # to build your documentation
23 | # See https://docs.readthedocs.io/en/stable/guides/reproducible-builds.html
24 | python:
25 | install:
26 | - requirements: docs/requirements.txt
27 |
--------------------------------------------------------------------------------
|