Governance Update: self-nominations for the initial group of Jujutsu Maintainers are open!

[thoughtpolice]

Howdy *,

After a lot of deliberation and drafting, we've finally published our first draft the Jujutsu Governance structure! Go check it out! Enjoy the beautiful prose, and please fix my typos. It's almost over... Almost!

While we're open to feedback on the governance structure — open questions, rule clarifications, general structural refinements — one key component is something we will begin now: we need to elect an initial group of Five Maintainers to jumpstart the whole process and be responsible for decision making.

What's a Maintainer?

Quoting the shiny GOVERNANCE.md draft:

At the top of the hierarchy are the Maintainers. We consider maintainers to
be the people who contribute, review, guide, and collectively make decisions
about the direction and scope of the project.

A typical maintainer is not only someone who has made "large" contributions, but
someone who has shown they are continuously committed to the project and its
community. Some expected responsibilities of maintainers include (but are not
exclusively limited to):

• Displaying a high level of commitment to the project and its community, and
  being a role model for others.
• Writing code — a lot of code, especially "glue code" or "grunt work";
  fixing bugs, improving processes, making judgments on dependencies, handling
  security vulnerabilities, and so on and so forth.
• Reviewing code submitted by others — with an eye to maintainability,
  performance, code quality, and "style" (fitting in with the project).
• Participating in design discussions, especially with regards to architecture
  or long-term vision.
• When necessary, participate in a collective voting process to resolve
  conflicts and make decisions for which there is no clear answer.

This is not an exhaustive list, nor is it intended that every maintainer does
each and every one of these individual tasks to equal amounts. Rather this is
only a guideline for what maintainers are expected to conceptually do.

In short, Maintainers are the outwardly visible stewards of the project.

Note that these rules are NOT all an explicit or exact requirement; if you participate actively but have less patches than other developers, that's OK! We won't be checking all your grades or anything.

What's the process for picking the initial group?

And after a bunch of deliberation, we've decided on a simple process:

• For the next three weeks¹, we will be taking open self-nominations from any existing contributor
  • Right here in this discussion thread!
  • That would mean nominations end on December 27th, 2024.
• Technically, nominations are open, meaning you can nominate anyone you like...
  • But in practice we suspect most people will self-select for this initial group.
• At the end of this, the initial set of maintainers will be decided upon by two beloved members of the community in private discussion, who will consist of the two initial Maintainers:
  • Martin von Zweigbergk (@martinvonz), and
  • Yuya Nishihara (@yuja)
• A final decision should be made in short order after the nomination period closes, barring holiday parties/vacation, travel shenanigans, etc.

To be clear: Yuya and Martin being part of the initial set means that means there are three open slots available! Many thanks to them, as they both graciously agreed to take on this burden and decide the initial set. (In case it isn't obvious, Martin and Yuya both are the de facto main contributors, reviewers, and maintainers; we felt it was both right and respectful of their labor to allow them this privilege, and we're very happy they accepted.)

How can you self-nominate?

• Post in this thread
• Introduce yourself; and maybe a sentence or two about what you've done, or want to achieve, or why you think you've got what it takes.

That's it!

What happens next? What if I get elected?

We're hoping that this will proceed independently of any reviews/updates to the governance document and expect it will be a relatively quiet and straightforward process. Once this is done, we'll update the governance document with the names of the chosen few and will proceed under the framework set there. We'll also announce it on all the regular channels.

To be clear: we don't expect the initial set of elected maintainers will need to do anything like weekly meetings, check-ins, etc. This is to be left up to their discretion, so don't worry; things can carry on as normal if you're elected. You won't need to pencil in anything on your schedule.

Anything else?

That's all from us. Now, let the games begin!

Footnotes

1. Three weeks has been chosen as an arbitrary number, but one important note is that Emily Shaffer is on leave at the moment, and we'd like to wait until she is able to review the governance document, and possibly self-nominate. ↩

[thoughtpolice]

To start the process:

I nominate myself, Austin Seipp (@thoughtpolice). I've been around for a little while now and involved in a bunch of areas from writing code, to helping users, to proselytizing endlessly my coworkers. Thanks for the time and consideration!

[tim-janik]

As a follow up, I'd like to nominate @ilyagr who I think is an outstanding contributor to the project.
He is always kind and helpful, patiently helps a newcomers on Github and Discord, goes the extra mile to connect the IRC community and as far as I can tell from my limited perspective is also quite knowledgeable about the source code. His PR feedback also seems to be spot on in the cases I have seen.

[arxanas]

I nominate myself, Waleed Khan (@arxanas) as a maintainer.

Open-source experience

I've been a jj contributor since 2021.

I've been working on git-branchless since 2020, which some readers may be familiar with. (git-branchless is an open-source project with similar goals as jj, but a different approach.)

Professional experience

I've spent my career working in developer infrastructure and tooling (LinkedIn), and I hope to bring specialized expertise to the maintainer group.

• Example: I implemented jj's Watchman integration specifically to handle large monorepos, based on relevant professional experience.

Among other things, I have worked on or adjacent to monorepo-scale source control tooling, including at companies like Meta and Twitter.

• Example: See Build-aware sparse checkouts for monorepo tooling I worked on at Twitter.

Note

At present (2024-12-16), my involvement in jj is personal, and does not represent any corporate interest.

Vision and goals

I'm passionate about improving the UX for developer tooling for novices and experts alike.

There are two main aspects of my long-term vision for jj:

• Novices and intermediate users should find the interface intuitive, predictable, and easy to experiment with.
  • Example: See git undo: We can do better for my thesis on how improving the developer feedback loop benefits novice users.
• Experts and power users should find the interface highly flexible and able to streamline common workflows.
  • Example: See git-branchless's git test for a workflow I'd like to bring to jj one day.

In doing so, I hope to bring unique technical and UX perspective to jj based on the relevant research. Some examples of the research I draw on:

• My original research:
  • Where are my Git UI features from the future? (2023)
  • Patch terminology (2024)
• Git UX research:
  • Gitless (2013–2016)
  • Investigating & Archiving the Scholarly Git Experience (2019–2022)
• Other source-control-related research:
  • Keeping master green at scale (2019)
  • Flake aware culprit finding (2021)
  • Lazy Merging: From a Potential of Universes to a Universe of Potentials (2023)