Governace via GitHub

DAO-Wide General Discussion
#1

Our current governance process has been functioning reasonably well for a while now, but relies heavily on this forum and results in a fair bit of duplicate work, along with attendant risk of issues and divergence between versions of proposals.

Ideally each proposal would live in only one place, and there’d be no need to copy them and edit them in multiple locations. At the same time, we need a persistent and stable URL for proposals so that they can be referred to in future, and the forum isn’t ideal for that.

I’d like to suggest the following changes to streamline and improve the governance/proposal process:

  1. Temp-checks remain as-is, as posts in the DAO-Wide -> Temp check category.
  2. Draft proposals are submitted by creating a pull request on the governance-docs GitHub repository, following a standard template. Forum discussions on a draft should link to the PR rather than reproducing it. Comments can be left directly on the PR.
  3. When a proposal is advanced to a vote, editors assign it a number and merge it. A snapshot vote is created linking to (but not reproducing) the contents of the proposal, and the proposal is updated to link to the live snapshot.
  4. When a proposal advances or is rejected, editors update the file in GitHub as per the current process.

This system will help reduce duplicated effort and overhead, and permit maintaining a single canonical version of each proposal. Thoughts?

  • Agree
  • Disagree

0 voters

1 Like
ENS DAO Newsletter #3 - 04/01/2022
#2

I do still like having the contents still reproduced in the body of the Snapshot proposal, because then there’s no chance of someone linking to a page on GitHub, and then changing it after the vote goes live right?

1 Like
#3

I agree with the intention, but I kind of worry Github might be a bit intimidating for the average person that doesn’t use it or understand it. I’m kind of speaking for myself here too because I still don’t exactly understand what pull requests are and how merging works. Maybe if there is a good walkthrough about it before the transition.

3 Likes
#4

While I like the idea as a long time Git user, I am afraid it might discourage average user without Git experience

1 Like
#5

I think any formal process would involve using a permalink to the specific revision of the file being voted on.

I’m optimistic this can be solved with documentation - and potentially with more technically capable people helping less technically capable authors get their drafts written.

I had initially included Gitbook pull requests as a viable option, but they don’t appear to have an option that allows anyone to view them without signing in, which rules them out as an effective way to share a draft.

3 Likes
#6

I like the idea of a single canonical version of each proposal.

As long as the person drafting the proposal is not required to use github and can designate someone else to submit the proposal on their behalf I’m in support.

1 Like
#7

I agree with the reasoning provided, but I’m hesitant because this risks decreasing transparency. Between Discord, Discourse and Twitter theres a lot for contributors to manage as it is. I could see discussions/comments going unnoticed because they occurred on Github.

Despite this, I’m open to trying it out so we don’t have to maintain docs in multiple places.

4 Likes
#8

It sounds like this would require everyone to use Github to contribute to the crafting of the proposal.

1 Like
#9

It could be a good excuse to onboard people to Git. Pull-Merge on simple text files is not that hard to grasp. Proposals not being code is a big advantage

3 Likes
#10

Hey all - jumping in a bit late here.

I would advise against migrating step 2 to GitHub as it is more exclusionary and requires a bit of technical knowledge / past experience. I would echo that the tech stack is becoming exhaustive.

While this is an optimistic scenario, it rarely happens in practice:

The result is more fragmented discussions and those who are truly passionate about improving the protocol (average tokenholders) are deterred from participation.

Can you think of instances where this proposal lifecycle and user journey has been pioneered by someone without a Git or developer knowledge?

#11

As a first (inclusive) step, I’ve created a GitHub project board that tracks the status of current proposals from Draft to final.

1 Like
#12

Any chance we could add old proposals as well? (final versions only of course)

#13

I’m happy to do so, but wasn’t sure there was much point, since there’s nothing to track any longer. Why do you want them added?

#14

No particular reason other than having them all in one place. If it takes too much time, let it go. Only suggested it for completeness than anything else

#15

I’ve created a PR to the docs to implement my suggested changes. If there are no strong objections I will merge it and we can try this model out for a while and see how it goes.

Update: I’ve now merged this PR.

2 Likes