Nominations are open and council members are already being put forward. Worth a pause before it becomes normal.
We built two bodies on purpose. The council leads. The CCs do the work and elect that leadership. That line is how the workers hold the leaders accountable. Put the same names on both sides and it disappears.
Councilors already have standing, recognition, and a say in direction. Stacking CC on top pools more power into the same few hands, and edges toward leadership helping elect its own council. Not a villain problem, a structure problem. You fix those early or not at all.
We’re still in the bootstrap period, so the precedent isn’t set. So I’ll just ask: do we want real separation between those who govern and those who elect? Tell me where I’m wrong… or if all of this has been decided before hand with majority … i’ve been outta this discussion
The CCs and the Council are two different bodies which have different functions. After this initial induction, CCs will be picking who is on the council going forward, and once the minimum count is hit (11) CCs will be the only inductors of further CCs. This has been carefully thought out and discussed in the open.
There are community members who are on the council who have an extensive record of contribution that makes them ready for CC status. There are other members of the council who have been around but their specific contributions up until their election are either limited or difficult to evaluate. They’re not getting inducted right now. They might after more time.
Our vision is that council members will primarily be selected from the CC body as it grows, as CC work is a strong way of demonstrating readiness for the large project-wide responsibility. But in this case we have a body of people who have been contributing on a CC level who now need to be inducted to bootstrap this body, and the CC program has not existed until just now.
Thanks for the clarification. That makes the intended relationship between the Council and CCs a lot clearer to me.
I think the part I am still curious about is the bootstrap period specifically. Since the first eleven form the initial CC electorate, and the Council participates in inducting that group, I would still like to see as much diversity as possible among those first eleven. Different types of contributors, builders, miners, community members and people who are not already part of the Council.
Not because Council members are undeserving, but because this seems like the one point where the initial makeup of the group can have an outsized influence on what the CC body looks like going forward.
One other small procedural question. I see the Charter requires a Council member who is also a CC to recuse from voting on their own Council seat. During this bootstrap period, is there also a rule or expectation that a Council member recuses from voting on their own CC nomination?
Thanks gents. I’ll read the full thread and TIP properly, but my mind’s fairly made on the principle.
My one live concern is concentration, governance power, elector power, and token allocation all pooling into a small overlapping group. That’s the structural risk I keep coming back to.
I really appreciate the work the Council has been doing, and I think the Council has an important role to play in the project.
After reading through the RFC, though, I have some reservations about Council members also becoming Core Contributors. My concern isn’t about the individuals involved, but about maintaining healthy separation between the different parts of the governance structure.
The CC role already carries meaningful responsibilities and influence within the project, including electing the Council. At the same time, the Council has its own responsibilities and oversight role. I think there is value in having some separation between these groups so that influence and decision-making aren’t unnecessarily concentrated among the same small group of people.
I also appreciate that the RFC makes becoming a CC optional for Council members, rather than making it a requirement. Given that, I would personally prefer Council members to contribute through their Council role without also taking on a CC position.
For that reason, while I strongly support the work the Council is doing and have no issue with the individuals themselves, I will be voting against Council members becoming CCs. My vote is based on governance structure and maintaining a healthy distribution of influence, rather than on any particular person.
I must express particular frustration at this moment that after weeks of discussing this in the open and declaring what we were planning ahead of time, this is only now coming up. It could have been raised any time during that period of gathering consensus.
There is not such a rule. It wasn’t considered. I decided not to comment an upvote on my candidacy unless we just can’t get a council member to respond with a yes or no within window and we’re only a vote away. I’d suggest @naveen and @kinkajou take the same policy. CC induction requires 5 yes votes and no ‘no’ votes within the voting period.
You should support this based on that principle. The alternative is a supermajority of CCs being Tari Labs contributors. There are only a handful of community members who are ready for CC status. If you remove three of us (Kinkajou, myself, and Zhao), the balance is thrown way off, and then really screw things up for hitting the 11 person minimum for CC body self-management.
The best way to improve the situation is to grow the community and cultivate more members who are ready for CC status. Not to re-litigate what has been decided over excruciating back-and-forth consensus building work over weeks of time.
The current electorate for CCs is Council only. You can express your thoughts (as you are doing here) but do not have a vote. Once the first CCs are elected, they will also have votes. Once the 11 member threshhold is met, only CCs will have votes on inducting more CCs.
@0xhra , @GSXRspartan , and @Okz have well expressed their concerns about the possible reality of a revolving-door Council/CC organization. I share those concerns.
Unmentioned but important is the perception of such an arrangement. Council members immediately nominating one another is likely to lead to perception-based objections, and the response to those objecting can reinforce or diminish those objections.
@Fox , I understand your frustration at the objections coming now rather than during the public-comment period, but I suspect that many did not anticipate Council members immediately nominating one another nearly exclusively. @animalst , @sprucetree , and @blackwolfsa obviously already core contributors, lacking only induction into being Core Contributors. Additional nominees are almost entirely Council members, with the exception of Impala.
I would vote for Impala’s nomination, had I a voice. I also would nominate the three prior objectors in this thread - @Okz , @0xhra , and @GSXRspartan . Each of them has made notable contributions to Tari and clearly are (perhaps were) supportive of the project.
I agree with this, though I disagree that the optimal way to achieve this is to stack the Core Contributors with Council members while alienating those who are outstanding community candidates.
I share Fox’s frustration here for this reason. We gathered feedback for weeks, months even throughout this whole process, and this issue was never raised. In fact, it seemed the intended behavior and not an issue at all to many of us.
Of course the Council will be CC’s, the CC’s are going to elect people that contribute to Tari for the Tari Council and that’s how you become a CC. That’s presumably part of why the Council members were selected.
Also this. The reason Council members were nominated with the initial batch of CC’s is because all the rest were Tari Labs folks, and the Council has a mandate to help decentralize the project. If we just had an entire Council of Tari Labs, or Tari Labs + Impala, then we would have immediately centralized the program and failed at our mandate.
It’s in our charter that we have to establish the Core Contributor program and nominate the first batch of contributors within the first 90 days. People are complaining we are moving too slow, now there’s a problem that we are nominating certain people too soon, it’s hard for us to know how to navigate this dynamic. At least it’s hard for me. If we delay the community candidates that are ready then the CC program is centralized. If we nominate the community members on the council then the program is less centralized but isn’t perceived as such. There’s no right choice just one that’s obviously (to me) less wrong.
Who is being alienated? That was certainly not the intention of this program and I can assure you no one on the Council wants to alienate the community. We are the community too. The goal is to encourage community members to participate more.
I fail to see how nominating one excludes another because there is no cap on the number of Core Contributors we can have. The more the merrier. That just makes the body even more effective and decentralized.
Sorry for the doublepost but I would like to pose an alternative question(s) for the community to think on:
Should we be holding up nominations of otherwise completely qualified candidates due to how it is perceived by some members of the community? Shouldn’t we be nominating qualified candidates for the program completely on merits? Isn’t that what is best for Tari?
I understand the critiques about the perception here but I also notice no one is disputing any of the nominees qualifications. We talk about precedents, I worry that the precedent being set here will be far more harmful.
I understand the concern about overlap, and long term I would definitely like to see very little overlap between the Council and Core Contributors.
But we also need to be realistic about where Tari is today. The active community is still relatively small, and I am not sure there are enough people with the time, dedication and drive to cleanly separate those roles yet. We can either spin our wheels trying to create that separation immediately, or accept some overlap during the bootstrap stage and deliberately decentralize as the community grows.
Perhaps the better approach is to set a target for reducing overlap over time. Something like no more than 50% overlap after the first year, then 25% after the second. The exact numbers can be debated, but I think the principle is more useful than trying to force an ideal structure before the community is large enough to support it.
Glad to see everyone throwing out constructive ideas. Like Joseph said, look at the tough spot Tari is in right now. Once we bounce back and bring in more talent, we can look into decentralizing. Right now, my opinions is that cutting costs and ppl who can drive the project is the most appropriate approach. We should be glad that someone in our team is capable of handling both CC and council roles.
I understand the frustration @Fox and @kinkajou … some of us simply don’t have the time to read every single discussion and topic. I was personally occupied with the unclaimed airdrop discussion, so just flagging my thoughts here as I see them.
Regardless, I think @joseph makes a solid point about setting targets for decreasing overlap over time. @joseph, perhaps you can formalise it into an actual proposal and we can decide whether to proceed with it.
I support setting targets to reduce overlap over time, and I think the vast majority would agree.
Agreed with Joseph. I think we need an accurate number on this. Otherwise, we risk creating a situation where CCs are effectively electing the Council, while the Council is then voting on CCs. That kind of circular influence can easily lead to a “friends and family” dynamic, even if everyone involved is acting in good faith.
I think @joseph point about having a clearly defined structure around Council and CC overlap makes a lot of sense.
If heavy Council and CC overlap becomes normal from day one, it may be much harder to question that structure later because it will already be established as how the program works. That is why I think diversity in the initial group matters even though there is no limit on the total number of CCs.
I keep coming back to the idea of “we can always decentralize it more later.” The problem is, who gets to decide what happens later? It will largely be the people selected under the structure we create now.
That does not mean anyone currently being nominated is undeserving. I just think this is probably the easiest point in the program’s life to make sure the foundation includes a broad range of independent voices and perspectives, rather than trying to correct for concentration after the norms and voting body are already established. All in all, we can voice our opinions and make suggestions, but during the bootstrap period the final decision ultimately rests with the Council.
