Updates to the "CAP Core Team"

[Nicolas Barry]

Hello

With Protocol 23 “Wisk” now launched on the main network, the SDF is shifting focus toward the next series of protocol updates.

As a reminder, the CAP process (described in https://github.com/stellar/stellar-protocol/tree/master/core#cap-process ) involves several steps.

Prior to validator votes on protocol changes, the CAP process outlines multiple rounds of review and discussion with the broader community. This structure enables the progression of ideas into solutions that may be adopted by validators. Some steps require feedback and/or votes from a group called the “CAP Core Team”.

The purpose of the “CAP Core Team” is to include individuals with an understanding of both technical limitations and community priorities and maximize the chances that protocol changes are ratified by the validator community.

Previously, this team consisted of Jed McCaleb, David Mazieres, and Nicolas Barry. This composition was suitable when the Foundation was smaller and the ecosystem less extensive; however, both SDF and the Stellar ecosystem have since expanded (last change to this process was 6 years ago!).

To better align with current objectives and improve quality of feedback, some adjustments are being proposed, starting with SDF’s representation: the updated group will be Tomer Weller (Chief Product Officer, has a broad view on the Stellar Ecosystem), Anup Pani (Senior Engineering Manager, will keep the group honest on what is possible within the confines of stellar-core) and Nicolas Barry (Chief Technical Officer, broad technical view).

Further discussions will address additional improvements to the CAP process to make it even more relevant to the ecosystem.

Nicolas

[David Mazieres]

"'Nicolas Barry' via Stellar Developers" <stell...@googlegroups.com>
writes:

> Previously, this team consisted of Jed McCaleb, David Mazieres, and Nicolas
> Barry. This composition was suitable when the Foundation was smaller and
> the ecosystem less extensive; however, both SDF and the Stellar ecosystem
> have since expanded (last change to this process was 6 years ago!).
>
> To better align with current objectives and improve quality of feedback,
> some adjustments are being proposed, starting with SDF’s representation:
> the updated group will be Tomer Weller (Chief Product Officer, has a broad
> view on the Stellar Ecosystem), Anup Pani (Senior Engineering Manager, will
> keep the group honest on what is possible within the confines of
> stellar-core) and Nicolas Barry (Chief Technical Officer, broad technical
> view).

I support this change.

David

[John]

What is the full scope of adjustments? I think the current team includes important principled viewpoints. Their decentralized values may not carry over to the updated group.

How about we include members of the community? There are plenty of proven builders with diverse interests at stake. Keeping them in the quorum supports network expansion from all angles.

I think it makes sense to go beyond. As we expand T1 validators, everyone can stay on the same page with a chance to filter improvements based on their needs. Priorities can include feedback from acting operators.

John

[Nicolas Barry]

Changes are just what I mentioned above: the goal for this iteration is more of a house keeping one for SDF where we saw the quality of feedback on CAPs from the old group degrade because people didn't have time to attend.

To your point, I do want to find a way to evolve the CAP process further but this will take a bit more time to find something that fits the needs of the ecosystem and document it. We're working on codifying better certain expectations around validator operators, so this should fit nicely into those conversations.

Nicolas

[John]

I think the quality of feedback on CAPs matters a lot, since the committee is the last line of review before validator implementation. Whether we like it or not, the archival inconsistencies showcase general deferment to CAPs that make it through FCP, introducing risks despite the network's "feature completeness." The original post said "starting with SDF's representation" in an idea to "evolve the CAP process" to presumably include agents outside of the Foundation, which seems like a great idea given productive public forums to perfect developments responsibly.

I've discussed this with prominent community members, and I think we should expand this three-person group to include independent members who will consistently choose quality over adoption speed. Just as my concerns over the Protocol 20 bug took time to mature by a quorum, I prefer adequate public documentation over the 24-hour turnaround on 62 and 66 which were exploited in a month. If the vast holdings of lumens aren't enough incentive, then I would not trust complete power in the hands of Foundation members given the org's relatively uniform viewpoints which often seem lodged deep within opaque Slack chatter.

Blockchains should not update such critical governance mechanisms within 3 hours of proposal based only on the response of David's email. Might it be worth spending more than a few days approving these changes to receive enhanced written feedback from exceptional community members like Tim Baker or Johan Stén? I've risked my entire career on the decentralization of the network as a requisite to trade securities, and over the years of developing our frameworks we've always found stability in the structure of giving others who care the ability to make their concerns known and recognized in roadmapped efforts.

John

[Nicolas Barry]

Thanks for the feedback.

> Just as my concerns over the Protocol 20 bug took time to mature by a quorum, I prefer adequate public documentation over the 24-hour turnaround on 62 and 66 which were exploited in a month.

The "24 hours" is misleading, it does not represent deliberation time.

We (CAP Core Team) always voted in the same way: after CAP protocol meetings, if there is general consensus with the community (sometimes it takes many meetings) we move on to FCP. CAP 62 and 66 had broad support (both in threads and during the meeting) given their simplicity.

All CAP team members were present at that last meeting which allowed members to provide timely feedback to the proposers, this was exactly why we made the change (instead of asking missing CAP Core Team members to review the recorded meeting).

In terms of "community safety" --> the process is fairly simple. FCP does not mean the CAP will be accepted into a specific protocol version for a couple reasons.

* we use the 1-week grace period as a "last call" in case some community members missed the discussion threads and protocol meeting and want to voice any concern.

* post acceptance, and during (or after) implementation, the protocol change can still be abandoned/delayed -- this relies on people contributing to code reviews.

Historically, the vast majority of protocol bugs (including the recent one from protocol 24) are implementation bugs -- not design bugs (ie: the CAP has no issue and is correct).

If you want to help with the quality of changes, this is where we need the community's help as historically SDF has been on its own when it comes to reviewing and auditing core (with the exception of paying people to audit core).

Finally, if you have specific concerns about CAP 62 or 66, please respond to the appropriate thread.

Nicolas

--
You received this message because you are subscribed to the Google Groups "Stellar Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stellar-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/stellar-dev/a8840353-7271-4da5-a4b8-9311a8765da5n%40googlegroups.com.