SLP process proposal to encourage participation from ecosystem

[anupsdf]

what

Added SLP process proposal where anyone in the ecosystem can propose changes to the network limits.

why

To encourage participation from ecosystem. To clarify the SLP process. To empower Tier-1 organizations to govern the network.

[Copilot]

Pull request overview

Adds an SLP contribution/process section to limits/README.md to formalize how ecosystem participants can propose and advance Soroban resource limit changes through a committee + validator workflow.

Changes:

• Documented an SLP-specific contribution process modeled on the CAP contribution process.
• Introduced an “SLP Committee” concept and a draft-to-final progression for SLPs.
• Added guidance for drafting and iterating on SLPs (naming, assets, discussion venues, and status transitions).

[MonsieurNicolas]

we should not merge this until we've good rough alignment with tier-1.
let's get more feedback from people --> it's also an opportunity to simplify things

also, left some comments (in addition to Copilot comments that are also relevant)

[rice2000]

Two quick notes

[rice2000]

I tagged 3 spots for the same reason: we may want to consolidate discussion and SLP committee approval to Github rather than offering the mailing list as an option. That way, all the relevant info is in one place, which might make it easier to follow and participate.

[magofox]

Interesting proposal. I like the idea of more transparency and quicker action, particularly around the ledger key freeze component of SLP.

1. I am curious about how many of these SLP evaluation and votes are likely to occur in a month and the expected turn around time. Clearly a ledger key freeze proposal would need to be executed quickly, but how about a more generic request to increase transaction limits.
2. I'm also curious about the qualifications someone would ideally have that is representing the Tier 1 voting org. Ledger freeze actions seem more like a jury role, where any community member can make a call based on the facts presented to them. But a transaction limit feels very technical where hardware engineering knowhow would likely be needed. Or is this more like an elected board member of a public utility, where the people making the decision are just normal citizens being presented cases to decide by the general manager and staff at the utility (in this case, SDF).
3. While I agree decentralized governance is important, I cannot help but call out the elephant in the room. Stellar already asks a lot from its Tier 1 Validators with no inherent incentive to run a validator. We've seen a lot of Tier 1 validators come and go already, many times due to financial circumstances. The list of T1 validators is quite small with a pretty sizable barrier to entry for new entrance - technical knowhow, available capital and human resources, and, most importantly, trust. One way to view this proposal is placing another responsibility (requirement?) on the entities that are already the backbone of the network. This proposal, combined with some added incentive from the network to the validators, would feel like a more balanced and rounded proposal that would incentivize more robust and sustainable participation in running and governing the network.