Yeah its some secret keys, some Tari-labs specific projects thats I dont need access to
1 Like
I like requiring a unanimous vote to overrule a veto.
I like the idea of removing self-nomination; people can and will still approach core contributors directly asking for or discussing a nomination, and that will be a good first litmus test for a candidate’s viability.
I like the idea about category weighting when requesting access. If someone is applying to be a core developer, then it is the other maintainers of that codebase who would be best qualified to assess their capability. A social media manager/moderator is very well qualified to vote on someone’s character as a core contributor nominee, but not necessarily qualified to assess their code contributions.
Where I disagree is that I think Core Contributor concentration and centralization absolutely is a key issue and how access sounds like it’s being tied to the CC nomination. The core contributors elect the council. The entire reason we’re here is to facilitate a community takeover. That is our mandate and the point of this whole process - to make Tari more decentralized. That’s the point of having a Core Contributor program and not just maintaining the Tari Labs status quo.
In one year, are we just going to go back to Tari Labs control over the whole protocol without the ‘community takeover’ ever having materialized? The vast majority of the CC group if we tie it to “who needs access” will be Tari Labs employees, and that’s who will be voting in every additional CC and the next council? Why wouldn’t they vote for the people they know better/have worked with longer/have the longest track record of contributions? The only reason they weren’t voted in this time is because the Charter prohibited it explicitly. We will have managed to re-centralize the project entirely in less than 2 months.
To me, this was the appeal of the initial program as Fox wrote it. There are many different categories of Core Contributor, and you don’t necessarily need access to anything to be one - that’s a separate process. I was even worried there would be too many Core Contributor’s from the community with 5 nominations not being restrictive enough, perhaps dozens/hundreds in relatively short order, now I’m worried these proposals sound too restrictive and we’re over-correcting.
Consider the entirely hypothetical person of “Fox from 2-3mo ago” - running every Tari Show along with Naveen, contributing to the code on Github, submitting governance proposals, and is universally liked/respected/trusted by the community. Does this person need access to one platform or another? Maybe? That’s besides the point. The person I described is clearly a Core Contributor to the project whether or not they have some permission or credential, and I don’t think anyone here would dispute that.
If we’re just electing all of the Tari Labs folks right out of the gate (and they clearly are Core Contributors and so will be nominated), then there needs to be some balance from the community, or we need to change the threshold from which future CC nominations switch over from the Council to the CCs so a more “decentralized” (even if smaller) body is electing the initial Core Contributor group.
Like, instead of 5 CC’s being the threshold maybe the Council elects them until there’s 10. Or until there’s “(Tari Labs Employees*2)+1” Core Contributors. I’m not sure on a solution here, but I am certain we should be weary of centralizing the program as much as possible even initially.
Lastly, I think there should probably be an amendment process similar to the community charter - but I’m not sure if 2/3 majority of the council is enough and I don’t think the CC’s alone should be responsible for making changes to their own governing document. Maybe unanimous council vote? Or 6/7? I’d like to hear other’s thoughts.
I’ve spent a bit of time reflecting more today and I think I’m coming up with a better picture of how we can address some of the bigger issues here, based on y’all’s feedback.
As @kinkajou notes, the goal is indeed to spread out the CC voting body out more, with a wider array of viewpoints and skillsets, and to reduce the centralization on Tari Labs. As @blackwolfsa notes, one can be an important contributor without having merge access to specific repos. As @sprucetree has said, the honor of being a CC is not a set of checkboxes.
I have been a bit hung up on binding access with CC status for developers. On further reflection, this is probably not necessary:
- I wouldn’t expect any special access for other CC categories, like designers. Publishing a design somewhere doesn’t affect anyone’s installation until some coder implements it anyway.
- This norm of requiring a specific access grant alongside CC code status is more likely just a particular of the project I’ve spent the most time on. The Open edX project has many, MANY repositories and they always need more hands on them. So making sure each developer is a point person for at least one of them helps reduce the maintenance burden. We don’t have nearly as many.
- The Open edX project also isn’t running a financial system, so the risk profile is also different.
So, I am now convinced we can decouple access from CC status. This resolves concerns for several of you, but I do think one concern of mine is still outstanding, which is that I’m unsure if there is a good impetus to induct. Can we create one? Should we:
- Encourage people to reach out and ask a CC if they’d like to make a firm commitment to the project and become a CC, with the understanding that the CC has the discretion to put forth the nomination or decline then and there?
- Have a process/event of a recurring nature where we look for community members we feel are a good fit and invite them?
- Something else?
I don’t know that there’s enough inherent benefit to inducting CCs if they don’t certainly have more access, but I know the community benefits from having a solid body of CCs. I don’t think we want to do anything especially incentivizing to grow the body, since that could mean it grows more than it should. But having a way to make sure that the possibility is evaluated for given contributors is important, since otherwise we’d expect the status quo of just having contributors stay normal contributors to happen.
One of my biggest issues is the whole point of asking for rights. What ever we call this, core contributer, maintainer etc. Name does not matter.
If someone asks for merge rights, or admin rights or some rights, I immediately see warning lights. Why are these rights required.
Giving these rights out should be on invite, and in my head I see the following scenarios:
- Lead maintainer comes to council and says they cant cope with the amount of work to merge, they want to nominate person x, as additional lead maintainer.
- Lead maintainer resigns, so they and council nominate a replacement.
- Lead maintainer goes rogue, so council removes them and council nominates a new lead maintainer.
I cant for see any reason why we would want to risk having someone apply to be a lead maintainer and its some “check” boxes and now they are one.
Every single lead maintainer is a security risk by broadening the attack surface, and I include myself here. Someone can hack into my pc, my accounts etc. The more accounts that have access the more changes there are. An attacker only needs to be lucky once, we need to be lucky every single time.
3 Likes
OK. I have updated the proposal. Rights are now unbundled from induction.
Instead, the proposal now indicates that CCs will be “the first (and in most cases, only) people considered for project access.” I say ‘in most cases’ because there are a handful of project resources that might be council-only, and some lower-stakes access which may be granted to non-CC contributors to do work (issue refinement, wiki article writing, etc) which can lead to later CC induction.
Nomination no longer requires including specific access grants, and the proposal now explicitly states access is granted on an as-needed basis.
@blackwolfsa @sprucetree @kinkajou Please let me know if this addresses your concerns.
1 Like
On my outstanding concern about incentive to induct:
What if we:
- Required that all pull requests be reviewed by at least one Code CC before merge (non-CCs can still do an initial review pass, but a CC other than the author must perform a review for all PRs)
- Have a twice-a-year contributor review (a good occasion to gather stats and learn about how the community is growing) where contributors who are ready may be highlighted by the reviewer, if any? This could be handled by one of the Project CCs.
The first would give incentive to ensure that contributors with merge rights are keeping a healthy level of additional contributors around their repositories without requiring additional access to be granted or being overbearing, as no one wants to either be stymied by having too many reviews to do or too few reviewers to look over their work.
The second would allow for a mindful, periodic induction and would work especially well for CC categories where code isn’t involved.
RightsCategory Expansion
Expansion of rightscategories is done similar to nomination. A forum post requesting rights or category expansion, with reason given and evidence of competency supplied, shall be made. If after 5 working days there are at least three affirmative votes and no negative votes, access shall be granted. Voting rights are the same as described in Nomination.
Just to clarify - a category expansion would be, for example, an ecosystem CC becoming a code CC or vice versa?
A date, 10 business days from the date of posting, by which any votes for or against their candidacy must be given
Can we just raise this to 14 days? 10 business days is confusing IMO and every day is a business day in crypto anyway.
Any override vote must be completed within 10 business days, and must include publicly published reasoning for the override, and their view of the evidence in light of the standards in this document. Otherwise, the answer is 'no.'
Same here - 14 days pls.
I was under the impression that this was already how things worked. A Code CC review should absolutely be mandatory for every PR. 2 CC’s sign off on every PR.
I like this idea as sort of a mandatory/prescheduled review of the project/contributors. I assume this is in addition to CC’s being allowed to submit nominations at any time, though?
I’m still concerned about the initial CC balance if we’re inducting all the current Tari Labs folks at the creation of this program.
I feel like raising the threshold from 5, or just making it a time limit e.g. 90 days after program initialization and it switches over from the Council, are the simplest solutions here? Maybe some folks in the community have input?
Correct!
Fair point. Done.
For most PRs, this has been the case (as far as I know). But there’s a funny thing that happens when new contributors start contributing consistently-- they start to become the best reviewer for some aspect of a repository, and a CC will find themselves reaching for their review. If they keep having to add another CC on top of it due to process, it’s a good sign that this person should be a CC.
In the case of the RFCs repository mentioned earlier, my role in composing the TIP process has made me the preferred reviewer for a few PRs there now, so they’ve been merged without a CC’s review, just a CC’s authoring. Based on context, this is perfectly acceptable practice as it stands. However if the requirement became hard that a CC must review, and it went on long enough, it would chafe enough to encourage solving the problem via induction.
Yep! I don’t think the semi-annual thing necessarily needs to be part of this proposal, either-- it can just be a thing we do and write down the process for in the wiki, since it’s not ‘law’ per se and we can expect the character of it to change as we do it more and learn how to best leverage it. It might also become more or less frequent once we get the cadence down.
The eval is just a way to make sure that CCs are prompted to make nominations consistently-- but those nominations are still CC-submitted, and can be done at any time.
Having real numbers would help here. We know @sprucetree @blackwolfsa @stanimal and @possum would be in this set. @naveen How many more are we expecting would be in this initial group?
Making it to where the council votes until the initial count/balance is right seems the most straightforward way to handle this, and doesn’t run the risk of the clock running out if it turns out finding enough qualified people takes a few months more.
1 Like
Who is a big issue here, take L1 Core for example,
No one does reviews except me atm, no ones reviews my code atm. I hate it, but no one is involved enough to ask for reviews. And then saying we need to induct a new core 1 member in 90 days? Okay Who?
If we put some arbitrary number down there, it sounds great in theory, but in practice I think its just going to be kicked down the road, or we are going to chose some sub par person just to tick a box.
No one said anything about a L1 code CC.
There are multiple different categories of Core Contributor for exactly this reason. The majority have nothing to do with the core code, and access has been decoupled from Core Contributor status already based on our feedback.
I agree putting a timer on it is probably a bad idea and risks pressuring the council into rushing to pick some candidate(s). Better just to raise the threshold.
I’d put forward that having any Code CC review that code would be preferable to having none review it. Even if the person isn’t deeply familiar with the implementation, they can still catch things like:
- Bugs that your eyes have made invisible due to you not having a fresh look at it
- Issues like functionality not having sufficient test coverage
- Making sure that another person can walk through the setup and test process after the changes.
- Spotting holes in the documentation
Over time, the goal is to make these repositories easier to contribute to. Ensuring someone is always reviewing PRs ensures a baseline of approachability. Over time, if we’re successful in growing the project and attracting more Blockchain-aware devs to it, better contributors/revieweres with more familiarity will arrive, and they can be promoted to CC when they prove themselves.
None of this requires access to merge, of course.
I don’t think so-- we have the council’s entire term to fill those seats. Extra time can be taken to grow the project and find the right people. The council still has to take in the votes of the CCs when inducting-- they’re additional voters, not the only voters, and any ‘no’ vote from the existing CCs would require a unanimous override. So rushing won’t work.
Even if the term expires, the next council can continue the work of finding the right people, but current seat holders will know that the current CCs are majority Tari Labs and will be accountable for that fact if their term ends without finding an agreeable balance.
@naveen Did you get a count/listing of the current CCs so we can figure out the numbers here?
@blackwolfsa @sprucetree Does this plan address your needs?
I have pushed a revision which makes the following changes:
- After a conversation the council had about logistics for the community wallet, and now that the access has been decoupled from induction, wording to enable a CC to hold one of the keys to a large community multisignature wallet has been added, in addition to the existing wording about project wallets.
- There is now a ‘bootstrap period’ for CC nomination voting. The first 11 inductions will have Council members voting. After the 11th CC has been inducted, the council loses voting rights, and all voting power is vested in the CCs, except in the case of an appeal, where the council requires a unanimous vote to override.
- Instead of giving the council voting rights in the case that the number of CCs drops below 5 for some reason, we switch to unanimous votes being required by CCs. This prevents a potential maneuver where a compromised council might try to remove CCs to reinstate voting rights and then rebuild their voting base to their liking. This seems unlikely but felt better to make explicitly not permitted.
- It adds a requirement that changes to this particular TIP require unanimous vote from the council and majority vote from the CCs. This particular piece of law needs to be very difficult to change to avoid things like a simple council majority clawing back all power from the CCs.
Please give the whole document another read-over to let me know if there’s anything else I should add, change, or remove, or anything else that is worthy of comment or concern. After all, that last item means that it will likely be solidified for quite some time.
If after 5 working days there are at least three affirmative votes and no negative votes, access shall be granted. Voting rights are the same as described in Nomination.
Can we change this to 7 days?
Done. I’ve also fixed the wording to say “the CC’s category will be expanded” rather than “access shall be granted”.
I realized I forgot to include the earlier suggested ‘CC must review all code’ point, and added it while I was there.
1 Like
I think for all things, we need to stick to calendar days. Work days are not the same across the globe.
2 Likes
I think that instance @kinkajou pointed out was the last one. I did a search for ‘business days’ last time but forgot to check for ‘working days’ as a synonym. Let me know if you see anymore, but I didn’t catch any on a read-through.
I dont have any concerns anymore. Just a curiosity question about the 11 members, how did you calculate 11?
It’s twice the number of CC’s being inducted from Tari Labs + 1
1 Like
I’m glad to see a lot of this has settled. I have notes.
Edit: I don’t know why formatting broke, but i’m not going to spend any time fixing it.
[quote=“Fox, post:28, topic:204”]
We know sprucetree blackwolfsa stanimal and possum would be in this set.
[/quote]
I’d assumed this set was smaller (2 people), and I was still going to argue we shouldn’t make people who’ve already proven themselves run the process again. Now that I see I’m in it, I’ll drop that. My point was mainly in support of backing the people who’ve been doing the work, and making a gesture for them, not myself, but with my own name on the list it feels too self-serving to keep pushing.
[quote=“Fox, post:18, topic:204”]
I prefer this more flat arrangement rather than hierarchical view.
[/quote]
Flat’s fine, as long as access stays least-privilege and tied to actual responsibility. Flat should mean same standing with different responsibilities, not everyone accumulating the same access over time.
[quote=“kinkajou, post:40, topic:204”]
It’s twice the number of CC’s being inducted from Tari Labs + 1.
[/quote]
I don’t think this number 11 helps this TIP, and I’d cut the target. It takes a guess at the Labs headcount and builds a quota around it, and it doesn’t even guarantee the balance it’s reaching for. It bakes in a them-versus-us framing I’d rather we didn’t have. Sponsored teams are normal in open source, and the mix shifts on its own as the community grows. Nothing even stops us from hiring an already-inducted community CC, and there goes the ratio overnight (not that we’re looking to, the point is that the number is fragile). What I actually worry about is the incentive it sets up: a superfluous inflationary quota that eventually gets filled with weaker candidates just to hit an arbitrary figure. Induct on demonstrated trust. Don’t manufacture seats to satisfy a formula.
[quote=“Fox, post:26, topic:204”]
Have a twice-a-year contributor review (a good occasion to gather stats and learn about how the community is growing).
[/quote]
This one I’d drop. It’s make-work without a clear job to do. A review on a schedule pushes us to pick the best of a small current pool just to fill seats, instead of waiting for genuinely strong people to rise on their own through steady work and real relationships. If nobody’s rising, the fix is finding the actual barrier, not adding a review. This is the thread running through all my notes: the more process and rigidity we bolt on, the more we screen out the good candidates instead of surfacing them.
[quote=“Fox, post:25, topic:204”]
Required that all pull requests be reviewed by at least one Code CC before merge.
[/quote]
No argument that every PR needs CC review. What I’d add is that the reviewer has to know the repo or the domain, especially on security-sensitive code. Any Code CC reviewing any PR meets the letter and misses the point. Word it as a qualified reviewer, not just a Code CC, so a safety rule doesn’t turn into pressure to induct more people as simply having more people, doesn’t qualify them to reduce the bottleneck.
> …they may be removed from the program by a majority vote of the council and have all CC rights revoked.
This is the one I’d actually change. CCs run induction, but they have no say when the council removes one of their own. That’s lopsided.
It’s also out of step with the TIP’s own amendment rule:
> This document may only be amended or replaced via unanimous vote of the council and majority vote of the CCs.
Changing the document takes both bodies. Removing a person takes a council majority alone. Removal should be at least as deliberate as editing the text that governs it. Put it at the same bar: unanimous council plus a majority of CCs. Careful in, careful out.
> One key from a set of signature keys for multisig community wallets (if also approved by supermajority (2/3) council vote)
This reads as a council matter, not a CC one. I can’t think of a reason being a Core Contributor should make someone eligible to sign for community funds. If the council needs custodians for a multisig, that’s a council appointment with its own security policy, based on what the wallet holds and who should guard it. Custody of community funds and CC status are separate things. Keep them on separate tracks.