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 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 high likelyhood their work will be discarded.

@jack do you have any thoughts on how this could be improved? Off the top of my head this seems like a process and coordination issue.


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:

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 community. We shared our spec multiple times and hand many convos: but mostly in the SDK and Tendermint slack, not in the forum, which would have perhaps been appropriate.
Where we chose to have these convos is quite important. Also in relationship to governance convos. I myself am going to endeavor to do better to engage with the forum (like you did Martin!). I think starting there is a good anchor. We’ve not been the best at that.

Martin Dyring-Andersen, [21 Jun 2019 at 15.05.27]:
Yeah, that is probably why we need some better process… At least I was not aware of the work being done when commenting on the GH issue by b-harvest.
Aaron @cpt_grog just to be clear this is not really directed at you guys, I appreciate the work you are doing as I think everybody else is… I am just trying to start a discussion about the process, so we can (hopefully) improve it.

Gregory | Regen Network, [21 Jun 2019 at 15.09.15]:
Totally understood Martin. Not taking it personally: just filling in details. As Aaron notes we weren’t thinking of it beyond our tram and discussions were centered around Tendermint Inc team mostly. That may be a pattern to watch for.

Hyung B-Harvest, [21 Jun 2019 at 15.09.20]:
I also remember talking about key management with @ethansf , I wish I had talked with him more before we dig deeper on this subject.
We are totally happy about Aaron 's expanded version of subkey with better potential. Not a criticism from us either, just a regret that I could do better communication

Henrik Aasted Sørensen, [21 Jun 2019 at 15.12.04]:
Nice to get some context. Thanks, guys. So does anyone have an outline of the roadmap from here to including the subkey functionality in a Cosmos-SDK release? Is anyone planning to take ownership of that process with PRs, code reviews etc? Or have AiB signalled that they will drive that process from here?

Hyung B-Harvest, [21 Jun 2019 at 15.14.07]:
I also talked about our spec with several dev team members and does not inform me about any info related to another process from other team. Maybe team wants some decentralized parallel contribution :slight_smile:

Henrik Aasted Sørensen, [21 Jun 2019 at 15.14.45]:
Even though an implementation exists, there is still some ways to go with a lot of relatively “boring” work before it’s available on the hub.

Gregory | Regen Network, [21 Jun 2019 at 15.16.14]:
We will be working on this for sure. It’s in our roadmap. We can communicate details. Timeline is of course related to our success fundraising right now.

Gregory | Regen Network, [21 Jun 2019 at 15.17.43]:
Also possible that since we were more focused on a different use of a similar function, the similarities were lost in translation.
It all points to a strong desire for collaboration and communication. Which is fantastic in my eyes.

Martin Dyring-Andersen, [21 Jun 2019 at 15.19.45 (21/06/2019, 15.19.58)]:
Just thinking out loud here… Since you guys are busy with regen specifics and it seems your subkey impl. is good, would it make sense to decouple the process of getting subkeys into cosmos-sdk and let outside team work on it?
I think subkeys are widely useful so would like to see it making it into cosmos-sdk sooner rather than later, but obviously understand you guys are busy with your project.

Hyung B-Harvest, [21 Jun 2019 at 15.20.28]:
I agree, it looks like different purpose but technically very same implementation

Azulito, [21 Jun 2019 at 15.21.25]:
I think the key missing point here is a product owner. That is responsible for vetting what goes into cosmos Sdk.
Many groups will fork Sdk and add cool. Useful features for their projects. However the value really comes when many that are commonly useful are refined (maybe with 2-3 approaches in forks) and a canonical version makes it into upstream Sdk.

Martin Dyring-Andersen, [21 Jun 2019 at 15.22.41]:
Agree, but we need to formalize that process… And project owner = @jackzampolin here?

Azulito, [21 Jun 2019 at 15.22.44]:
I don’t even try to make prs on tendermint / cosmos, as the approval process is not very clear to me. I’m happy to share ideas and code, and if someone wants to put upstream, great. It is all apache. But the energy to organize prs is too much for me
I guess it would be Jack, but I haven’t seen him very present in these discussions or moving prs forward. He is product owner of cosmos/gaia for sure. I think there may need another one for the Sdk, independent of just gaia usage
Now that gaia and sdk are separating repos, I think the fact that gaia is just one user facing app, and the Sdk is a more collective work, is becoming clear

Henrik Aasted Sørensen, [21 Jun 2019 at 15.25.10]:
My feeling is that it would be valuable if some Cosmos-SDK core developers were assigned specifically to integrate externally supplied solutions. Scour the various forks and pick what matches the general roadmap.

Gregory | Regen Network, [21 Jun 2019 at 15.25.39]:
Yes we’d be happy to prioritize this and anything else more broadly useful in our timeline. This is already a priority. We can’t launch without it. :slight_smile:

Azulito, [21 Jun 2019 at 15.25.48]:
My feeling has been that pr reviews are low priority for internal code. And very low priority for external code.

Asmodat San, [21 Jun 2019 at 15.26.20]:
Also would be good if roadmap was maitained again which was mentioned many times
it was before the first release. It should also include esitmated timelines for future updates

Martin Dyring-Andersen, [21 Jun 2019 at 15.27.26]:
Understood, but I think there is substantial work to get your changes upstreamed and deployed on the cosmoshub as well. Perhaps it would make sense to “outsource” this work, as it is not business critical for regen?

Hyung B-Harvest, [21 Jun 2019 at 15.28.27]:
just a question, do we need team’s permission to PR a code if we already get the Gov proposal passed?

Gregory | Regen Network, [21 Jun 2019 at 15.28.28]:
Yes, if indeed there is governance will for the hub, it would make sense for the community fund or ICF to find a specific dev team to focus on that aspect, in cooperation with us.

Hyung B-Harvest, [21 Jun 2019 at 15.29.03]:
Pr would be much simple with Gov feature I guess

Henrik Aasted Sørensen, [21 Jun 2019 at 15.31.04]:
That’s not great, although it’s probably due to swamped with internal stuff.

Martin Dyring-Andersen, [21 Jun 2019 at 15.31.33]:
It is a bit of chicken-and-egg thing, as just the work the create a proposal and lobbying it is substantial. Hm…

Henrik Aasted Sørensen, [21 Jun 2019 at 15.31.35 (21/06/2019, 15.31.51)]:
But bad for community involvement motivation

Azulito, [21 Jun 2019 at 15.32.32]:
I don’t take it personally. I see cosmos employees waiting 2 weeks for pr reviews on something clearly on their roadmap.
Lots of coding going on, but bringing it to master is a difficult process

Hyung B-Harvest, [21 Jun 2019 at 15.33.03]:
I think processing a governance proposal will make it easier and faster
If team reject any pr that is passed by community, it is centralized SDK management

Azulito, [21 Jun 2019 at 15.34.17]:
Or the cosmos governance board forks cosmos Sdk and maintains a community version of the Sdk.
Assuming there is a community mandate and funds for a few very active maintainers to coordinate projects and merge prs

Hyung B-Harvest, [21 Jun 2019 at 15.34.58]:
I think SDK for the hub should belong to community

Michelle, [21 Jun 2019 at 15.35.10]:
I think a good place for this would be the Cosmos SDK community calls?
Jack leads those and it could be a place to discuss these items

Gregory | Regen Network, [21 Jun 2019 at 15.35.34]:
If @dlguddus or others want to lead lobbying etc, I think ( pending a convo with Aaron ) we can commit to the dev side on this PR.

Henrik Aasted Sørensen, [21 Jun 2019 at 15.35.59 (21/06/2019, 15.36.10)]:
Sounds like a great forum. Wasn’t aware of them, to be honest. :slightly_smiling_face: Do you have a link with more info, @MichelleMari ?

Hyung B-Harvest, [21 Jun 2019 at 15.36.18]:
Interested :slight_smile:

Gregory | Regen Network, [21 Jun 2019 at 15.36.23]:
We are always on them! Jack does a fantastic job!
Sdk calls are Thursday’s at 2 pm Easter US time.

Michelle, [21 Jun 2019 at 15.37.27]:
Yes and we want it to be a place where the community can discuss these points together
Next Thursday at 8 pm CEST
it is bi-weekly

Gregory | Regen Network, [21 Jun 2019 at 15.37.50]:

Michelle, [21 Jun 2019 at 15.37.53]: dial in is here

Henrik Aasted Sørensen, [21 Jun 2019 at 15.38.22]:
Thanks, guys.

Gregory | Regen Network, [21 Jun 2019 at 15.38.36]:
I bet you can communicate with @jackzampolin to get an invite. He posted here and we responded which is how we started

Hyung B-Harvest, [21 Jun 2019 at 15.38.45]:
Great. We will be there on next meet

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.