docs: update contributing guidelines

[robert-zaremba]

Description

Closes: #9814

• Updates the contributing page
• Adds contributing guidelines

NOTE:

• This pr doesn't update the code owners section. We will still need to define it.

This is based on the discussion we had 2 months ago and recent chats.

---

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

• included the correct type prefix in the PR title
• added ! to the type prefix if API or client breaking change
• targeted the correct branch (see PR Targeting)
• provided a link to the relevant issue or specification
• followed the guidelines for building modules
• included the necessary unit and integration tests
• added a changelog entry to CHANGELOG.md
• included comments for documenting Go code
• updated the relevant documentation or specification
• reviewed "Files changed" and left comments if necessary
• confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

• confirmed the correct type prefix in the PR title
• confirmed ! in the type prefix if API or client breaking change
• confirmed all author checklist items have been addressed
• reviewed state machine logic
• reviewed API design and naming
• reviewed documentation is accurate
• reviewed tests and test coverage
• manually tested (if applicable)

[barriebyron]

I might win an award for the most granular review of words and grammar in this most important release resource! In a past life in a different job, I was heavily invested in the release cycles. I absolutely applaud this important information and clarity regarding releases. thank you Cosmos SDK code owners!! I appreciate you. lmk if this feedback is helpful.

[barriebyron]

Suggested change

	Updates to the release branch should come from `master` by backporting PRs (usually done by automatic cherry pick followed by a PRs to the release branch). The backports must be marked using `backport/Y` label in PR for master.
	Updates to the release branch come only from `master` by backporting PRs (usually done by automatic cherry-pick followed by PRs to the release branch). The backports must be marked using `backport/Y` label in PR for master.

[robert-zaremba]

In fact the original text is correct. "Should" has to be used. Updates which are not related to the upstream, must be created as PR to the release branch.

[barriebyron]

okay, not critical for me... although should is ambiguous... I think we're saying that

Updates to the release branch can be made only from master by...

(isn't this fun? I can talk word choice all day long, love this stuff!)

[barriebyron]

approving, some seriously important content here!

[clevinson]

Thanks for taking the time to work on this @robert-zaremba !

After reading through it, I think the new contributing-guidelines.md doc is actually pretty valuable. Maybe there could be a better name, but I think for now its fine.

When talking about release process, I feel like there's a lot of overlap w/ the Stable Releases document (which in general should maybe be renamed?). And there's also some content in CONTRIBUTING.md that I feel should go in CONTRIBUTING-GUIDELINES.md.

Can you provide a bit of context as to how you see the high level distinction between these different pages? I think that would make reviewing this PR easier, so I could give more concrete suggestions about how some sections might be better in other .md pages.

[clevinson]

Suggested change

	+ code must be always deterministic
	+ code must be always deterministic

Is this a type of exploit? Or a more general security concern.

[robert-zaremba]

both, if we have a nondetermism trap, which could be exploited, then the network can potentially halt.
Do you suggest to "shift it to the left'?

[clevinson]

I think this is great to outline and document in the Repo, but I'm not sure it belongs in the CONTRIBUTING-GUIDELINES.md doc. Maybe its better in its own doc around QA practices and scope & team members & outcomes?

Or maybe a pinned issue similar to what we have for working groups?

[robert-zaremba]

Why a pinned issue? Do you think it will have a better visibility? For me issues are something that will have it's own life and will be closed eventually.

[clevinson]

We should probably add a note to the "Testing" section above and be a bit more clear about what functional / acceptance testing folks should be doing, and also provide an example (both in SDK and resource for how to write acceptance tests).

Then again, since we don't have any acceptance tests in the SDK yet, I'm wondering if its better for us to implement some for existing modules first so we can point to those as examples?

[robert-zaremba]

I reorganize this section.

Re adding acceptance tests: this should be iterative process and I hope we will soon have them.

[robert-zaremba]

@clevinson , the idea is that:

• CONTRIBUTING - a general document about how to contribute and the PR / review policies.
• CONTRIBUTING-GUIDELINES - a document describing how to design a code in contrast to the process of contribution flow (issue / discussion -> draft -> pr -> review -> release).

When thinking about better name for the latter document, I decided to rename it to CODING-GUIDELINES. What do you think?

[amaury1093]

LGTM, thanks @robert-zaremba for writing this.

IMO a lot of release procedure stuff can probably go in another doc (maybe STABLE_RELEASES.md, maybe even a new .md), so that CONTRIBUTING.md is cleaner and targetted at a general public.

But okay to merge it as-is, the release process is finally documented, thanks!

[robert-zaremba]

@clevinson , @AmauryM - merged STABLE_RELEASES.md with Release process from CONTRIBUTING into RELEASE_PROCESS.md. Let me know if you want to have another look.

[amaury1093]

this lgtm!