Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce temporary voting process to approve jj governance structures #4400

Merged
merged 1 commit into from
Sep 12, 2024

Conversation

nasamuffin
Copy link
Contributor

Hi! I'm Emily, part of the governance working group. I am not a regular contributor to jj, but part of my role at Google is to guide open source projects in Martin's and my organization, helping make sure our upstream communities are healthy and productive.

The governance working group (me, @arxanas, @thoughtpolice, and @martinvonz) wants to be able to get community approval on governance structure changes. Bootstrapping is hard - how do you get community approval for a process to get community approval? - so we're introducing this process by the normal pull request workflow.

Things to keep in mind:

  • This process is temporary! It will go away, replaced by something longer-lasting and more robust.
  • Until this PR is merged, the governance working group is open to suggestions to clarify the language. But again, this is a temporary process - it doesn't need to be perfect, it just needs to be good enough for a handful of uses and then it can be discarded.

Things I'm especially interested in during review:

  • Is the wording clear and unambiguous? Is it easy to understand how this process is supposed to work?
  • Did I do the documentation change correctly? Do we actually want this governance/ dir? (FWIW, I ran cargo doc and it passed with warnings unrelated to this file, but I'll openly admit that this is the first time I've built anything in jj and I might have missed :) )

Copy link
Collaborator

@steveklabnik steveklabnik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sounds great to me!

@PhilipMetzger
Copy link
Collaborator

PhilipMetzger commented Sep 6, 2024

While this is LGTM, shouldn't the temporary governance be RFC 0? So I'd move it under docs/governance/rfc/rfc-0-temporary-voting.md.

@nasamuffin
Copy link
Contributor Author

While this is LGTM, shouldn't the temporary governance be RFC 0? So I'd move it under docs/governance/rfc/rfc-0-temporary-voting.md.

Oh interesting! Would you rather see this doc explicitly outline that new proposals should go in docs/governance/rfc/ and approved proposals move into docs/governance/?

@PhilipMetzger
Copy link
Collaborator

Oh interesting! Would you rather see this doc explicitly outline that new proposals should go in docs/governance/rfc/ and approved proposals move into docs/governance/?

Since it lays it out as that we start a RFC process, kinda (it also reminded me of my comment here #1411 (comment)). I'm not sure that they should move though, as each RFC could also have a "approved:" field with the final decision.

@nasamuffin
Copy link
Contributor Author

Since it lays it out as that we start a RFC process

Kinda. But kinda not :) It's a temporary process - one of the things we want to use this process to approve is an actual formal RFC process. So I don't know if I want to unilaterally guess what that RFC process is (that's one thing the working group hasn't talked about yet pretty much at all). Although it's easy to move things around later if we change our minds.

@gulbanana
Copy link
Collaborator

looks pretty good. certainly adequate for a bootstrap process

@PhilipMetzger
Copy link
Collaborator

Kinda. But kinda not :) It's a temporary process - one of the things we want to use this process to approve is an actual formal RFC process. So I don't know if I want to unilaterally guess what that RFC process is (that's one thing the working group hasn't talked about yet pretty much at all).

Since it's fine as is, we can postpone this and keep the governance/rfc/ idea for the future.

@ilyagr
Copy link
Collaborator

ilyagr commented Sep 9, 2024

Did I do the documentation change correctly? Do we actually want this governance/ dir? (FWIW, I ran cargo doc and it passed with warnings unrelated to this file, but I'll openly admit that this is the first time I've built anything in jj and I might have missed :) )

Since CI passed, we know that this builds fine, but if you really wanted to check it manually, you'd need to use mkdocs build or mkdocs serve as explained in the contributing doc. I think it's not really necessary; the main reason to do it would be to check that it will look good on the website, but it's very likely fine, we can make cosmetic changes later, and most importantly it's unlikely to confuse users even if something is wrong.

Copy link
Collaborator

@ilyagr ilyagr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great to me.

I'm approving this in the "if it were up to me..." sense, not in the "I'm sure everyone agrees" sense.

docs/governance/temporary-voting.md Outdated Show resolved Hide resolved
@steveklabnik
Copy link
Collaborator

Rust's "this is the RFC for the RFC process" ended up being RFC 2, let alone zero, haha!

I have no strong opinions on the topic, just thought it was a fun fact.

In order for the governance working group to make progress establishing
jj's governance structure, we need the approval of the jj community.

Set up a temporary voting process to get that approval.

Additionally, set up a governance dir for other governance-related
documentation to sit in.

Later, when we have a permanent governance structure and enough policy
to let the community make changes without needing the governance working
group, we can delete this document.
@martinvonz martinvonz merged commit 5aa6fa5 into jj-vcs:main Sep 12, 2024
18 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants