Skip to content

Commit 5ca849c

Browse files
authored
Add blog post about maintainer intuition from Jupyter (#546)
1 parent bb08337 commit 5ca849c

File tree

8 files changed

+136
-94
lines changed

8 files changed

+136
-94
lines changed
565 KB
Loading
Lines changed: 44 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,44 @@
1+
---
2+
title: "Yuvi on scaling maintainer intuition to facilitate PR review with PR triage boards"
3+
date: "2025-11-19"
4+
categories:
5+
- upstream-impact
6+
tags:
7+
- open source
8+
- community
9+
- learning
10+
featured: false
11+
---
12+
13+
Yuvi has a recent post on the [Jupyter blog](https://jupyter.org) on how his "maintainer intuition" about reviewable pull requests grew into the open-source [`pr-triage-board-bot`](https://github.com/jupyter/pr-triage-board-bot), a reusable workflow that keeps GitHub Project boards curated for the JupyterHub, JupyterLab, and GeoJupyter communities. [Foundational contributions](../foundational-contributions/) are rellay important to 2i2c. This is a great example of building clever technical systems that help maintainers prioritize the social work of facilitating contributions to keep ecosystems healthy.
14+
15+
{{< figure src="featured.png" title="The [JupyterHub PR Triage board](https://github.com/orgs/jupyterhub/projects/4/views/9)." >}}
16+
17+
Yuvi frames the problem here:
18+
19+
> Reviewing PRs is a critical way that maintainers keep an open source project moving forward, but identifying PRs that can productively be merged is hard.
20+
21+
And notes that _human scalability_ is often a big bottleneck:
22+
23+
> One key bottleneck we identified in the process was Step 2. In particular, I was relying on my maintainer intuition to pick a single PR that I believe can be merged, so others in the team can do review work. I started exploring what this intuition is, and if it can be scaled.
24+
25+
Here's his list of "intuitions" that he uses to choose PRs to work on:
26+
27+
> 1. PRs that aren’t too big, and are a reasonable size that can be merged within a 2 week window
28+
> 1. CI tests passing, so at least our automated checks haven’t caught any issues with it
29+
Features or bug fixes that I believe add value to the project and move us in the right direction towards being able to support our users as they need (this is the hardest!)
30+
> 1. If the author of the PR is a newish contributor, as I want to encourage them to stick around by being responsive to their gift. All PRs are gifts that we may or may not choose to accept, but should do so with grace.
31+
> 1. How long ago the PR was opened. There is such a big difference between a response to your PR 2 days after you make it vs 2 months vs 2 years. I prioritized newer PRs.
32+
> 1. What kind of contribution is it primarily? Different engineers on our team have different skillsets (JS, Python, etc) and I wanted to match the PR to what the engineer preferred code reviewing.
33+
34+
And the board essentially tries to capture many of these intuitions by signal-boosting them in one place:
35+
36+
> we can roughly say ‘Pick a PR that looks good to you from the top of the “First Time Contributor” or “Seasoned Contributor” list’, and that relieves me from being the bottleneck quite a bit.
37+
38+
Read more in the original article: [Scaling "Maintainer Intuition" with Pull Request Triage Boards](https://blog.jupyter.org/scaling-maintainer-intuition-with-pull-request-triage-boards-779f2387498b).
39+
40+
## Acknowledgements
41+
42+
- [Project Jupyter](../../../collaborators/jupyter/) for trusting us to incubate and now donate the bot code to the broader ecosystem.
43+
- [JupyterHub](../../../collaborators/jupyterhub/) and [GeoJupyter](../../../collaborators/geojupyter/) contributors who tested the triage views and fed real maintainer workflows back into the design.
44+
- [Jason Grout](https://github.com/jasongrout), [Raniere Silva](https://github.com/rgaiacs), and [Matt Fisher](https://github.com/mfisher87) for spotting the experiment early and helping it land across multiple orgs.

content/blog/README.md

Lines changed: 1 addition & 91 deletions
Original file line numberDiff line numberDiff line change
@@ -5,94 +5,4 @@ _build:
55
render: 'never'
66
---
77

8-
Our goal is to make blogging as short and quick as we can, so we can blog often.
9-
See [the template blog post](./_template-post/index.md) for an example template to use.
10-
11-
## How to write blog posts
12-
13-
Follow these steps:
14-
15-
- Copy the `content/blog/_template-post` folder into the appopriate year folder, and modify the folder name.
16-
- Modify `index.md` to fit your post. Do these things:
17-
- Generate post content using the linked posts in `_template-post/index.md` as inspiration.
18-
- The post should be short, to the point, and scannable. Use quick and accessible language, keep posts below 200 words.
19-
- If there are links in the issue, scan their content to learn more before you write the post.
20-
- Make sure to add an acknowledgements section at the bottom. Do these things:
21-
- check the `/content/collaborators` folder to see if an entry exists for that collaborator, and link them if so.
22-
23-
24-
### Example from Yuvi's doepy talk
25-
26-
Here's an example from a recent talk that Yuvi gave:
27-
28-
- Example GitHub issue: https://github.com/2i2c-org/2i2c-org.github.io/issues/470
29-
- The blog post that followed: ../../content/blog/2025/doepy-yuvi/index.md
30-
31-
### Example incident report
32-
33-
Incident reports are a way to provide transparency about what happened and what we learned as we run infrastructure. We create incident reports at https://github.com/2i2c-org/incident-reports so blog post GitHub issues don't need to have any content other than a link to the report.
34-
35-
- Example incident report issue: https://github.com/2i2c-org/2i2c-org.github.io/issues/482
36-
- The blog post that followed: ../../content/blog/2025/incident-ucmerced-throttling
37-
## How to write our Hugo directives
38-
39-
Here are a few example Hugo directives for quick reference.
40-
41-
### Figures
42-
43-
An example figure directive:
44-
45-
{{< figure src="images/staging-hub-matrix.png" title="Our staging and support hub job matrix tells GitHub Actions to deploy staging and support upgrades that act as canaries and stop production deploys if they fail.">}}
46-
47-
### Videos
48-
49-
From YouTube:
50-
51-
{{< youtube YjonPLxDiwM >}}
52-
53-
Local Videos:
54-
55-
{{< video src="videos/jupyterhub-admin.mp4">}}
56-
57-
### Callouts and admonitions
58-
59-
An example admonition / callout:
60-
61-
{{% callout %}}
62-
63-
Here's some markdown in my callout!
64-
65-
{{% /callout %}}
66-
67-
68-
## How to add a category and tags
69-
70-
Each post has one category and multiple tags. Categories describe the post's intent, and tags cover its main themes or topics. You add them to the frontmatter of posts like so:
71-
72-
```markdown
73-
---
74-
title: Post title
75-
date: "2025-01-01"
76-
categories:
77-
- updates
78-
tags:
79-
- open source
80-
- geoscience
81-
---
82-
```
83-
84-
## How to use categories and tags
85-
86-
We use **lowercase formatting** as well as **spaces instead of hyphens** for both tags and categories. For example, `open source`, not `open-source` and not `Open Source`.
87-
88-
### Common categories
89-
90-
We try to keep the number of categories small, and non-overlapping in their meaning. [Here's a list of all our categories](https://2i2c.org/categories/), but we try to keep it only to the ones below:
91-
92-
- `impact` - telling stories of impact that 2i2c has had, either via contributors to a domain / open source community, or via communities we've enabled with our service.
93-
- `service` - updates about our service and work we've recently done for it.
94-
- `organization` - updates about our organization that isn't directly related to our service
95-
96-
### Common tags
97-
98-
We have a lot of tags, so don't worry about creating a new one if you don't think your tag has been covered yet. [Here's a list of all our tags](https://2i2c.org/tags/).
8+
For information about contributing to the blog, see the [blog contributing guide](../../contribute/blog.md).
File renamed without changes.
File renamed without changes.

content/blog/_template-post/learning-post.md renamed to content/blog/_templates/learning-post/index.md

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,4 @@
11
---
2-
# THIS IS A TEMPLATE FOR COPY-PASTING TO MAKE IT EASIER TO CREATE BLOG POSTS
32
title: "TIL: How to do XYZ thing for Y outcome"
43
date: "1000-01-01"
54
authors:
Lines changed: 30 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,30 @@
1+
---
2+
title: "[Person's name] on [Topic]"
3+
date: "1000-01-01"
4+
authors:
5+
- Foo
6+
categories:
7+
- learning
8+
tags:
9+
- Foo
10+
---
11+
12+
One or two sentences describing a piece of content that you'd like to reference, its main takeaway, its author, and why it's worth reading (add a link to it and the author's name).
13+
14+
Some things that stood out to us:
15+
16+
Quotes, images, etc from the post that you'd like to highlight. Just one or two is fine, but add as much as you like. Make sure you're using exact quotes!
17+
18+
They mention ____ about ____
19+
20+
> Pull quote
21+
22+
They also talk about ____
23+
24+
> Pull quote
25+
26+
Read more in the original article: [article title]([link]).
27+
28+
## Acknowledgements
29+
30+
- Bulleted list of people and organizations to thank, with links to their spaces.

contribute/blog.md

Lines changed: 61 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -17,7 +17,7 @@ See the **Tags and categories** section below for inspiration about what to blog
1717
Copy the blog post folder template at the path below:
1818

1919
```
20-
content/blog/_template-post
20+
content/blog/_templates/[post-type]/index.md
2121
```
2222

2323
It contains an `index.md` file that you can modify. Put it in the folder for the year in which you're posting (e.g.: `content/blog/2025/mypostfolder`).
@@ -100,4 +100,63 @@ _Tags are more fluid, you can add as many to a post as you like._
100100

101101
#### Domains
102102
- `earth-science` - (here are common ones, add new domain tags as you wish)
103-
- `biology`
103+
- `biology`
104+
105+
## How to write blog posts
106+
107+
Follow these steps:
108+
109+
- **Find a GitHub issue**. An issue should describe the most important points to convey in a post. Read it, and any linked material inside, to learn what it's about.
110+
- **Choose a template**. Copy one of the `content/blog/_templates/[posttype]/` folders into the appopriate year folder, and modify the folder name.
111+
- **Read the template guidance**. Each template file has suggestions for its structure, as well as links to example posts - reda those posts to understand what we're going for.
112+
- **Generate a post draft**. The post should be short, to the point, and scannable. Use quick and accessible language, keep posts around 100-300 words.
113+
- **Add collaborator links**. Scan the post for mention of collaborating people and organizations - check the `/content/collaborators` folder to see if an entry exists for any you notice. If so, add a link to that folder entry.
114+
115+
116+
### How to add a category and tags
117+
118+
Each post has one category and multiple tags. Categories describe the post's intent, and tags cover its main themes or topics. You add them to the frontmatter of posts like so:
119+
120+
```markdown
121+
---
122+
title: Post title
123+
date: "2025-01-01"
124+
categories:
125+
- updates
126+
tags:
127+
- open source
128+
- geoscience
129+
---
130+
```
131+
132+
We use **lowercase formatting** as well as **spaces instead of hyphens** for both tags and categories. For example, `open source`, not `open-source` and not `Open Source`.
133+
134+
## Hugo directives you can use in our blog
135+
136+
Here are a few example Hugo directives for quick reference.
137+
138+
### Figures
139+
140+
An example figure directive:
141+
142+
{{< figure src="images/staging-hub-matrix.png" title="Our staging and support hub job matrix tells GitHub Actions to deploy staging and support upgrades that act as canaries and stop production deploys if they fail.">}}
143+
144+
### Videos
145+
146+
From YouTube:
147+
148+
{{< youtube YjonPLxDiwM >}}
149+
150+
Local Videos:
151+
152+
{{< video src="videos/jupyterhub-admin.mp4">}}
153+
154+
### Callouts and admonitions
155+
156+
An example admonition / callout:
157+
158+
{{% callout %}}
159+
160+
Here's some markdown in my callout!
161+
162+
{{% /callout %}}

0 commit comments

Comments
 (0)