feat: Core Contributor Program

[Kelketek]

Description

This Pull Request adds a TIP for the Core Contributor Program.

Motivation and Context

The Tari Council is required to establish a Core Contributor program within 90 days of inauguration. This begins the work and provides a framework for the project, including requirements for induction, scope, and voting rights.

How Has This Been Tested?

Locally. Render seems fine.

[claytonbittle]

First, credit due to @Kelketek for a strong skeleton. The AI-codegen responsibility clause is better than many projects have. The affirmative re-declaration for incumbents adheres to the charter's no-presumed-renewal principle. Scoped grants being least-privilege is the right approach, and the 72-hour public reasoning requirement on removals exceeds the charter's ask. The "not yet, not never" feedback culture is the right approach, in my view. Everything below follows in that spirit.

Speaking for myself, not the council. Disclosure up front: I hold an enterprise/ecosystem seat on the inaugural council and would plausibly qualify under the first category I'm proposing. Consider my advocacy in that context.

1. Ecosystem is missing as a category while the charter makes reference to it.
Article VI's rubric list includes "ecosystem development" verbatim; Article VII's contribution list does as well and the charter requires the Council to reflect "development, infrastructure, community, and enterprise." The four categories here (Code, Product, Community, Project) have no home for integrations, partnerships, BD, or enterprise adoption. Because this TIP makes CCs the exclusive electors of the council, the category list is effectively the electorate: leaving ecosystem out means the enterprise perspective the charter mandates has no constituency that can vote for it. A proposed inclusion, matching the existing format:

Ecosystem CCs

Ecosystem CCs grow Tari beyond its own repositories: the integrations, partnerships, and real-world adoption built on top of the protocol. Ecosystem CCs might do things like:

• Source and support integrations with exchanges, wallets, payment processors, and other protocols
• Source and develop partnerships with businesses and institutions that bring real-world usage to Tari
• Support third-party teams building on Tari with onboarding, technical liaison, and go-to-market help
• Represent Tari with enterprises, at industry events, and in adjacent ecosystems
• Advise the council on ecosystem strategy, deal structure, and market development

A parallel gap likely exists for Infrastructure (e.g. node operators, seed nodes, and devops aren't Code CCs). Pointing this out for whomever will represent this group.

2. Admission mechanics conflict with charter Article VI.
The charter says the Council "shall admit contributors who meet the rubric's threshold and shall publish each admission decision with a written explanation referencing the rubric and the evidence considered." By contrast, this TIP has admission determined by a peer vote: five affirmatives are required, and a single 'no' defeats the nomination outright. Two issues: (a) it's a blackball where one incumbent CC can gatekeep the electorate indefinitely, with no way to override or appeal; and (b) it shifts admission authority from the council-against-published-rubric to peer unanimity. Suggested reconciliation: keep CC voting as the primary mechanism, but a 'no' triggers council adjudication against the rubric with the written explanation the charter already requires, rather than auto-failing the candidate.

3. The bootstrap veto deserves a fix before it's ever used.
While fewer than five CCs exist, council members vote on admissions. Combined with the single-'no' rule, any one councilor (including the Tari Labs seat) can unilaterally veto members of the founding electorate. Even if never exercised, it's a standing exhibit for anyone arguing the council is a sock puppet body. Recommend that during bootstrap, a 'no' escalates to a majority vote of the full council with published reasoning, instead of acting as an instant veto.

4. The Review Panel is missing from Involuntary Exits.
Article VI guarantees a revoked contributor may request an ad hoc Review Panel per Article IV. The 72-hour public-reason requirement here is a good addition, but the appeal right needs to carry over into this TIP. Taken with the admission mechanics in (2) and (3), the draft currently has gatekeeping on ingress and no way to appeal on egress. It's worth closing both doors in the same pass.

5. Evidence and example thresholds.
The charter requires the rubric to define 'categories, evidence, and example thresholds.' This TIP delivers the categories; the other two are missing. The three Cs are the right values, but they're values, not evidence standards. Each category should carry two or three example thresholds (Code: N merged non-trivial PRs over M months; Ecosystem: a shipped integration, an executed partnership, or sustained third-party builder support with counterparty attestation). Ecosystem evidence especially needs defining, since the work often doesn't produce a public link. Attestation from counterparties or the council is how that work stays verifiable, and should count as evidence.

6. Wallet signature powers shouldn't follow the standard rights-expansion path.
The TIP lists 'signature powers for specific wallets' as a grantable right, which means the Rights Expansion path applies: three affirmatives, no objections, 7 working days. Anything touching funds falls under Article III (the Council governs the community token allocation) and should require explicit council approval. I'd suggest re-positioning wallet and financial powers out of the standard expansion path and requiring explicit council approval instead.

7. The TIP defines who has standing but doesn't yet define how decisions flow.
Probably a follow-up TIP rather than scope creep on this one, but throwing it out there: A decision-rights table covering what contributors and CCs decide, what passes by council lazy consensus versus requiring a formal vote, and what a decision item must include before it reaches the council agenda (plain-English summary, recommendation, and the relevant CC or workgroup's position on the matter). This is the bit that keeps council votes from turning into live design sessions (which we have already skirted around), and lets any member, technical or not, bridge the gap between day-to-day dev work and a council decision.

Smaller items: (1) The Project category anchor links to #product-ccs. (2) The PR description says 30 days but the charter (Article VI) says 90. (3) The timelines mixes business days, working days, and calendar weeks. It would be best to make it one unit throughout. (4) IRV is specified, but staggered terms will produce multi-seat election batches, which need STV or explicit per-seat races. (5) Rolling per-councilor elections every few weeks will be administratively heavy. Batching seats into shared election windows would solve this, and would simplify (4) as well.

None of this is a "no." It's a "not yet," in following with the spirit this TIP proposes. Can turn any of the above into PR-ready text if needed.

— Clayton / solix78, Tari Council (speaking for myself)

[Kelketek]

Thanks, @claytonbittle . This is excellent feedback. I've pushed a change that should address most of your notes:

1. Ecosystem is missing as a category while the charter makes reference to it.

I've included your wording for Ecosystem CCs.

2. Admission mechanics conflict with charter Article VI.
   The charter says the Council "shall admit contributors who meet the rubric's threshold and shall publish each admission decision with a written explanation referencing the rubric and the evidence considered." By contrast, this TIP has admission determined by a peer vote: five affirmatives are required, and a single 'no' defeats the nomination outright. Two issues: (a) it's a blackball where one incumbent CC can gatekeep the electorate indefinitely, with no way to override or appeal; and (b) it shifts admission authority from the council-against-published-rubric to peer unanimity. Suggested reconciliation: keep CC voting as the primary mechanism, but a 'no' triggers council adjudication against the rubric with the written explanation the charter already requires, rather than auto-failing the candidate.

I've taken your recommended solution, but have also stipulated that it be a supermajority. The council should need to feel very strongly about overriding CC judgement. Ultimately, if a CC is consistently blocking new CCs from being added for poor reasons, they could be removed under conduct reasoning per the involuntary removals clause.

3. The bootstrap veto deserves a fix before it's ever used.

The fix is inferred by the previously mentioned fix.

6. Wallet signature powers shouldn't follow the standard rights-expansion path.

I've added a note that this specific power must require an additional supermajority vote from the council.

7. The TIP defines who has standing but doesn't yet define how decisions flow.

I do think this is scope creep, and might be better addressed by a follow-up summary TIP or article for publication on a wiki in the future.

(2) The PR description says 30 days but the charter (Article VI) says 90. (3) The timelines mixes business days, working days, and calendar weeks. It would be best to make it one unit throughout.

Fixed the description. Made the handling of days business days almost everywhere. The exception was elections, which I felt were better served by calendar dates.

IRV is specified, but staggered terms will produce multi-seat election batches, which need STV or explicit per-seat races.

I think this is actually more of an issue that needs to be addressed in either the charter or via one-off council action to stagger the seats. Currently, all six council members have started their terms at the same time, and would end them at the same time, which doesn't satisfy the staggered terms the charter mentions. We may need to have some special one-time extension election for a randomly selected set of half of the council, but that's outside the scope of this document.

Two sets of elections a year could do it or every other year if we want to do two-year terms. These are just ideas, not anything I'm hard recommending yet, but we should address them after the most immediate critical items are handled so it doesn't become an issue.