Contributing

[tac0turtle]

How should someone contribute to ideas? Once a burner-chain is accepted into the repo what would be the next steps.

If I wanted to see about starting work on one of the chains in my free time, how do I go about making that known and what would be the next steps?

[okwme]

Great Question. Here's my proposal:

All Burner Chains Repo (aib)

This repo should be used to workshop ideas around potential chains. If/When there is consensus that a chain should go forward it should be marked In-Progress and get its own repo within the cosmos org. A link to this repo should be added (as well as added to the Awesome Repo). If the burner chain becomes operational it should be markedOperational.

Specific Burner Chain Repo (cosmos)

Each chain should have enough of its own concept/branding that a mono-repo for all burner-chains would feel restricting. Having a specific repo per chain might also make it easier to install a specific chain without having to download all other chains at the same time (this might be moot, I don't know if it's possible to go get a sub directory).

Issues and PRs would be made against that chain specific repo and the operation and implementation of it would be guided by participants inside and outside of aib. The contents of the Specific Burner Repo should include the following:

• README.md
  • Welcomes user to the repo and explains the concept of burner chains. Explains the purpose and reasoning behind this specific chain. Links to all relevant material about the chain including a block explorer if available.
  • It would be nice if each burner chain had its own branding. CC @allinbits/design-team
• /burner
  • This directory for the actual app. This is where the daemon and cli go.
  • /x
    • This directory is where custom modules for the chain go. Some chains should strive to eventually move the contents of this dir into the Modules Repo.
• /genesis
  • This is where all versions of genesis go
• /bin
  • This is where all versions of binaries go for every "release" of the chain
• /ui
  • This is where a website should go. At a minimum this website is a reproduction of the README.md located in the root of the project describing the purpose and status of the chain as well as all relevant links. At the other end of the spectrum this website could be a full fledged front end interacting with the chain, and maybe even the most important part of the repo.
• /tutorials
  • Unsure of how we should integrate tutorials here with sdk-tutorials and docs.cosmos.network. Could put files here and then add CI commands within tutorial repo to build into docs website. I think we should discuss a roadmap for tutorials in general to decide how they function with scaffold and burner chains in mind.

--

Notes

This is a just a starting proposal. Let's identify all of the problems here and make suggestions for improvements or additions that are currently left out. Something still missing is the launch sequence and marketing plan for each burner chain. I imagine these will be different for each chain so might not make sense to plan that part already. Might also be good to use this repo for that info since it should probably be private information (altho currently this repo is public).

[ethanfrey]

I agree completely with a single-repo per burner chain. Many may come from cosmos devs. Others from outside (like cosmwasm chain).

I also just saw the https://github.com/cosmos/awesome link - cool idea. Is this promoted much? Do people read it?

For me the idea that the burner chain repo include:

• go code for app
• compiled binaries for every release (and every major platform?)
• ui
• tutorials
• genesis for testnets

Seems restrictive.

I would agree that all of that info should be present and linked to from the README. For me, having the go application code, along with genesis files in one repo makes sense (and a brief readme with each genesis file on how to connect). The compiled binaries can be published in the github releases pages, rather than in a bin directory, much like gaia does.

A sample UI app can be it's own repo (or repos). I would contain links along with testnet genesis files to stock apps eg. big dipper, lunie, etc working with this chain. But app-specific UI code is likely different build system than the go app code, and can live in a different repo.

Same with tutorial.

Ex. for cosmwasm, I would have cosmwasm/wasmd or such, that included the app and testnet info and precompiled releases. I would have a readme that points to www.cosmwasm.com (and the github repo) for documentation/tutorial. And I would have multiple repos with smart-contracts and simple dApps - but a canonical list should be maintained in the wasmd README.

At least this is what makes sense to me.

I must admit, I feel keeping track of all public contracts will become a hard feat if this catches on. As well as dApps - maybe an "awesome" repo with PRs for listing? But that is likely cosmwasm-specific. Other chains will have a ui or two. (Cosmos has about 10 and they all have their own repos).

Hope this makes sense