Volunteers eager to help

28 views
Skip to first unread message

Blaise Pabon

unread,
Jul 25, 2023, 12:09:41 PM7/25/23
to sphinx-dev
TL;DR: Folks want to help with the repo housekeeping,  who do we talk to?

Some of us in the WriteTheDocs Slack would like to contribute... in fact we have PRs waiting to be approved (that's how much we want to contribute) It looks like the project could use a few extra hands to handle CI and triage (eg. simple typo fixes sit around without merging).

Who can we contact to about making life easier?

Blaise Pabon

Kayce Basques

unread,
Jul 25, 2023, 4:36:27 PM7/25/23
to sphinx-dev
I posted the thread in the Write The Docs Slack that kicked off this discussion.

We on Pigweed (https://pigweed.dev) love Sphinx and it's pretty mission-critical infrastructure for us now. So it's not hard for me to justify helping out with Sphinx as part of my work duties.

(Before reposting the discussion over on Write The Docs Slack, I just want to mention first that I respect the challenges of maintaining open source projects and hope that everything comes off respectfully and compassionately. My intention here is 100% "I like this project and want to help ensure its continued success".)

Here is my original comment from Write The Docs Slack for context:

I'm a bit discouraged about contributing to Sphinx after submitting this fix and watching it not get any attention for ~3 months. But I figure it's a good opportunity to learn where I went wrong. I guess I should have got confirmation from a core contributor to work on this before submitting a PR? It was labeled a "good first bug" so I figured a fix would be welcome. @Blaise mentioned that there are contributor meetings. Any where else where I can / should introduce myself? Maybe just start on super small fixes and build up a history of contributions? Any other suggestions? https://github.com/sphinx-doc/sphinx/pull/11390


Two suggestions / points of discussion worth considering (I didn't write these but agree with the sentiment):

The contribution guide only talks about creating pull requests. Nothing about CI, prioritization, contributor meetings, etc.
LOTS of pull requests waiting to merge, even simpler doc typo corrections.

Jared gave me a thoughtful and reasonable response about what may have happened:

My guess is you just picked a "bad" first issue with it involving the themes. It was labeled "good first issue" in 2016 (the definition of "good" has likely aged in 7 years) and I think the modern thinking is bundling so many themes in Sphinx was a bad idea (as someone that has maintained themes on a popular legacy open source project...it is): https://github.com/sphinx-doc/sphinx/issues/10672. Cleaning issues in the cobwebs can be a good thing, but it can also increase the chance of getting bit by a spider. And if the change ends up breaking something, it is likely the maintainer is on the hook to figure out the fix (or forced to revert and end up back at the same place minus hours of work and a bit of credibility).
So I think these types of changes (while they fix old bugs) are seen as cumbersome (theme changes are hard to test thoroughly) to parts of the code base that are starting to be seen as a "dead man walking".
But in general, I think small fixes that require small review cycles is a good way to build rapport, as  well as attempting to answer/guide/troubleshoot people in the issues. Also a big rapport builder can be working on things you don't want to work on (and that no one really wants to work on) so that other people might work on things of yours that they don't want to work on. It is a gamble, but most trust building exercises are (don't worry I'll catch you).
TL;DR: Don't get discouraged, but also maybe don't start with a theme related issue (unfortunately, at this point in time, until their tech debt is paid off).

Reply all
Reply to author
Forward
0 new messages