Best practice for community led runtime upgrade about runtimes

[rphmeier]

Here is my personal opinion on the broader issue:

The Kusama and Polkadot networks pay the fellowships to write, maintain, and improve the runtime code which is deployed on them. The networks reserve the right to disband, reorganize, or replace the fellowship at any time.

The only reason I see for bypassing the Fellowship is if the Fellowship refuses to implement or integrate some functionality which is desired, i.e. when the Fellowship is working counter to the interest of the network. In that case, OpenGov would be able to use its powers to disband or replace the fellowship, as it's not doing what it's paid to do.

Accepting an alternative runtime binary should in practice be a last resort when the fellowship isn't providing binaries that behave the way the network wants them to.

[rphmeier]

i.e. pushing code directly to OpenGov is a very roundabout way of asking for a pull request. Either
a) The Fellowship is still producing runtime upgrades that are good, in which case they would need to pull in the code that was submitted out-of-band if accepted. Why not just make a PR?
b) The Fellowship is not producing runtime upgrades that are good, in which case the fellowship need to be restructured by OpenGov anyway and this is a moot point.

The fellowship is designed to accept code upgrades originating from outside of its ranks both in the architecture phase (RFCs), and the implementation phase (PRs)

[senseless]

@rphmeier Would you (and the other fellows) be against doing this atypically in order to set precedent? I think it would be seen as a big W by the community and would be good for overall morale. Adam can submit a PR and we could move forward with this vote.

[adamsteeber]

I'd like the Fellowship to look at this from the perspective of someone outside of its ranks. In theory the idea of submitting RFCs and PRs to appeal to the Fellowship sounds reasonable, but in practice these publications usually either a) get totally ignored or b) become an interesting discussion with no real follow-up.

In the example of referendum 235, the idea of reconfiguring spending limits has been an active and open discussion in the ecosystem since the end of March when I posted my first Treasury analysis forum post. Unfortunately, despite @shawntabrizi inviting feedback and discussion, no one reached out to me to help get coordinated on a PR and I wasn't even aware of the RFC workflow. And even now, this issue of "best practices" is being raised and discussed in the Fellowship instead of the attention of the Fellowship being directed to my PR containing these changes (shout-out to @ggwpez for bringing his attention to the PR, thank you). This confirms what I expressed concern for in response to Shawn's initial feedback:

I’m hesitant to create a PR since I highly doubt Parity will spend the time to merge something like this. Wouldn’t it just be better to prepare a referendum instead? Isn’t that the whole point of openGov? That way token holders can decide on this in a separate referendum instead of it being lumped together with other technical upgrades.

If the Fellowship is responsible for fielding the ideas and concerns of the entire ecosystem, then as a paid organization its general community support is quite lacking from what I've seen in my experience. So in this specific instance, it's a matter of the Fellowship ignoring something that the community has expressed concern for - unsustainable Treasury spending.

The change in referendum 235 is also non-neutral, i.e. it adjusts hard-coded parameters in the runtime. @rphmeier you once said,

I do think that it'd be reasonable for the community to e.g. pressure the fellowship to leave code neutral, i.e. avoid setting parameters or activating features directly within runtime upgrades, or to build more infrastructure that makes performance concerns of baking parameters/feature activations directly into the runtime code moot.

So as a non-member, I'm expected to cry "devs do something" and wait for someone in the Fellowship to maybe implement a feature that allows governance to manage spending limits and other track parameters? Can't you see how that might make someone like me feel powerless? Especially when the barrier of entry in the Fellowship seems quite high. Am I expected to write the code for that functionality myself? I can only do so much technically given my area of expertise is in economics...

I'd also like to mention that I feel referendum 235 is my only resort; it's the only thing I can do to force everyone's hand. Perhaps I didn't exactly follow the correct escalation process or utilize the correct channels for requested changes, but I did garner a lot of attention and support on the Polkadot Forum - the Fellowship was certainly aware of the specific changes I was (and many others were) calling for. I was seeing a lot of nothing happening and as a non-member, I wasn't going to wait around for a Fellowship member to do something when I had the power to do something myself.

I want to caution the Fellowship against becoming a technocratic bureaucracy that sees itself as the only source of runtime upgrades. I believe the more authoritarian the Fellowship becomes the more it will diverge from the interests of the ecosystem as a whole. As a non-member attempting to make some very simple reconfigurations, I believe I have set an excellent example of conduct in getting those changes implemented. I believe a root track referendum is more than appropriate for simple runtime reconfigurations.

TL;DR - had I not submitted a referendum on chain, the spending track changes would have likely never been implemented or even voted on. What's a man to do? Obviously, the more complicated a runtime upgrade is the more scrupulous we should be in submitting it in the root track. But simple reconfigurations should be welcome in the root track.

[xlc]

@adamsteeber You can always PR changes to Polkadot and trying to get it merged. It can take time to get people's attention to review & approve them but it is possible to do so. Also I would like to remind everyone that Fellowship is an open collective. If you want to make code changes to Polkadot runtime, chances are you should try to join Fellowship. If you think people in Fellowship are not doing enough work in the directions you want, you could also get more developers to join and help get the work done.

[rphmeier]

I’m hesitant to create a PR since I highly doubt Parity will spend the time to merge something like this. Wouldn’t it just be better to prepare a referendum instead?

Let's go one step beyond that referendum being passed...isn't the intention of the referendum for this code to stay in the runtime and not be removed immediately afterwards? The changeset would need to be pulled into the fellowship repositories anyway.

So as a non-member, I'm expected to cry "devs do something" and wait for someone in the Fellowship to maybe implement a feature that allows governance to manage spending limits and other track parameters? Can't you see how that might make someone like me feel powerless

Anyone can open RFCs, comment on them, and discuss. The whole point is to empower the community to make changes while working with the fellowship even without holding expertise on specific implementation details. The only perspective I can provide in this repository is how to work with the Fellowship to bring more community input into the codebases it maintains, but there's not much to discuss if the outside contributor doesn't hold that intention to begin with.

Submitting non-fellowship upgrades needs to be possible in order to maintain the proper checks and balances and exactly to avoid the Fellowship having any monopoly over what features get included. But when non-Fellowship upgrades are accepted I can't see how it'd be interpreted as anything other than a signal that OpenGov believes that other developer organizations are producing better runtime upgrades than the Fellowship, which raises a lot of questions about the structure in the first place.

If other developer groups want to position themselves as a counter-elite to the Fellowship and win OpenGov's favor, then I'd say that's well within the scope of Polkadot as a system. As @xlc says, the Fellowship is designed to be an open organization and the culture & mechanisms are designed to avoid degraded situations where nuclear options are necessary.

In terms of an escalation path, I think there's something like this. Each step would be the subsequent escalation if the work doesn't get picked up and finished.

1. Propose an RFC to the fellowship after initial discussion
2. Get OpenGov to ratify the RFC with system.remark (if rejected/ignored by Fellowship)
3. OpenGov Referendum to signal to the Fellowship that progress must be made
4. OpenGov Referendum with alternative runtime binary (essentially a vote of no-confidence in the fellowship)

With this specific issue, and in general when discussing economic parameterization, setting specific values is often beyond the scope of the Fellowship's expertise and can be eagerly ratified by OpenGov in text form to guide the development and parameter-setting. Here we've skipped from 0 (initial discussion) to 4 (alt-runtime) without taking any of the intermediate steps or getting any "hard" commitment from OpenGov that this is desired.