Define how processes should get executed

[vsund]

https://github.com/blockstack/blockstack/issues/335 was part of a "lets define our regularly-happening processes and define them somewhere" (e.g. releases). This is not only extremely helpful for the respective maintainers but also for the community, later maintainers or people who get on-boarded.

Furthermore it assures that things which got extensively discussed get executed as decided because these decisions are a bit more visible than just an issue somewhere (support guidelines (see https://github.com/blockstack/blockstack/issues/377) and "repository hygiene" (see https://github.com/blockstack/blockstack/issues/327) are good examples for such things). Currently issues (also forum topics) get lost and picked up weeks later, probably risking that people dropping off.

This also would be great for better forming the emerging community around Blockstack. Especially Rust has done a great job with this. They have a fixed process for adding new feature to their language specification and the team has to run through them just like every external contribution (see here). They also do a yearly "State of Rust" survey (see here) which helps them with measuring how to they're currently doing.

[vsund]

Just remembered that we used RFCs at some point but somehow stopped using these.

[vsund]

This also helps to standardize/harmonize the processes for different processes and repositories 👍

This could go even as far as https://github.com/blockstack/blockstack/issues/362 begins.

[vsund]

After a short chat with @larrysalibra it seems that meeting notes would also fit perfectly into this. Currently they are stored in the forum (meeting category), blockstack/blockstack and sometimes in the corresponding repository ;)

[vsund]

Because this somehow got picked up (in form of a engineering handbook by @larrysalibra), I'm throwing in all my ideas here. Please note that these are just ideas, the handbook is yours, so take what you need from here :)

First of all, I think it would make sense to split it up into main categories like:

• recommendations
• guidelines
• rules / requirements

Topics it could deal with (not really a particular order, just raw ideas):

• scope (for future maintainers, community, self defining)
• ownership / responsibility (of repositories, issues)
• support (https://github.com/blockstack/blockstack/issues/377#issuecomment-351421030)
• repository (readme, branches, PRs, issues) hygiene (https://github.com/blockstack/blockstack/issues/327)
• documentation / testing
• feature process (rfc?, discussion period?)
• meeting process (schedule? notes?)
• workflow (commonflow, github flow, git flow)
• branching model (related to above), protected branches?
• versioning (https://semver.org?)
• release / deployment process
• (pull request) review process
• issue triaging
• bug triaging
• code style / standards
• commit message style (?)

There are also some other examples of these handbook (or more general process definitions):

• https://isobar-us.github.io/code-standards/ is a great definition of how Isobar does its front-end code and processes around it.
• https://about.gitlab.com/handbook/ are GitLab's company guidelines. They define their whole company through this.
• https://www.atlassian.com/team-playbook is a portal from Atlassian to improve teams by looking for recommendations on specific topics, might be some good content there :)