Process for cosmos-sdk changes

I am a bit concerned that new features/ideas will get stuck in limbo as a number of parties are working on the same problems, have done some research on the topic or simply have an opinion. This could lead to something akin to a “cookie licking” effect, where everybody might have an academic interest in a topic but none wants to assume responsibility of spec’ing, implementation and undertaking governance/deployment work. For changes to the cosmos-sdk it seems likely that the actual implementation part will be trivial compared to reaching consensus on the spec and deployment. A recent example of this would be account subkeys, which has seen work from @sunnya97 , later @bharvest and now the Gaians hackatom team. There was active work and discussion at https://github.com/cosmos/cosmos-sdk/issues/4480 which has now been terminated, making it unclear what the path forward is and what an implementation might look like. While I applaude all work on cosmos-sdk, I think as a community there is room to improve here as the process is clearly inefficient and as a result frustrating. It seems unlikely 3rd party developers will want to invest their time moving forward, if there is a…

Excerpt (1195 of 1378 characters). Read the whole post on the forum ↗

Thanks for brought this topic up. As one of the enthusiast team who wants to contribute to the community, I am worried that many others might also hesitate to research on topics because of topic overlapping issue.

I suggest to manage a list of ongoing research with categories, and if we see some overlapping feature, we should make proper communication and pre-agreement before implementation.

Also, items which is helpful but without any plan yet can be also listed so that contributors take any item to contribute. If one stated to dig an item, it should be her duty to transparently publish her specs and current process status.

And just replying to myself: This is not intended to be criticism towards anyone.

I see great working being done for all the right reasons, but we need a better process to ensure that the work is carried forward all the way into a cosmos-sdk release in a predictable manner that is acceptable to the wider community.

Treatment section on this page has some ideas: https://communitymgt.fandom.com/wiki/Cookie_Licking

I present, for your reading pleasure, a chat log from Telegram: Martin Dyring-Andersen, [21 Jun 2019 at 14.32.31]: Posted some thoughts on cosmos-sdk dev process based using SubKey as an example: Process for cosmos-sdk changes Hyung B-Harvest, [21 Jun 2019 at 14.50.58]: Hey Martin, you are always with my thoughts:) Martin Dyring-Andersen, [21 Jun 2019 at 14.56.07]: Yeah, I hope it is not seen as criticism - especially not towards Gaians team, as they did great work! But I think it would be nice to come up with a more organized approach to “key features” of cosmos-sdk moving forward. Aaron, [21 Jun 2019 at 15.03.19]: I just want to say that our work on this feature was initially just internal design for Regen Network, that it would be applicable for the broader community only became apparent to me when we were in Berlin and l am trying to coordinate with other people working on solving the same problem Gregory | Regen Network, [21 Jun 2019 at 15.03.19]: I think it misses some context, especially in missing the existence and sharing of the spec the Gaians team worked on which is nearly six months old. But i agree we need to think about this as a…

Excerpt (1195 of 10248 characters). Read the whole post on the forum ↗

We have a regular call for SDK contributors. Maybe we need a more formal process for setting agenda there (currently I’m just asking projects for pain points and feedback), more time (the calls are currently 30 min) and more of them (they are currently 2x/month).

I feel like those calls would be a great place for that kind of collaboration.