Quality Control for Protocol&API Changes

Does this mean we will not merge the proposal until the implementation is done and ready to be released? Otherwise it might not work well with the github project board.

I don’t think we need to block on that.

@nearmax I had a discussion with @matklad on the ownership of the implementation. More specifically, we agreed that it is the implementor’s responsibility to make sure that the implementation is properly tested and when they consider the implementation ready, they should submit a PR to stabilize the feature. This is similar to how Rust stabilizes nightly features and it takes off the burden from whoever manages the release on feature stabilization. What do you think?

By implementor you mean someone who owns the reference client implementation? This sounds consistent with what is happening on Ethereum where EIP proposers will monitor readiness of the implementations by various clients. I agree that this makes the most sense, we just need to think how to reduce the chance of feature being stalled by implementors indefinitely.

Yes

I agree. On the other hand, usually the implementor of the feature has motivation to push it forward (otherwise what’s the point of implementing it in the first place), so we just need to have proper guidance on when a feature should be considered ready and the process to stabilize it. cc @matklad