[RFC] Development and Release process

[stephenneuendorffer]

Below I've tried to capture the current practice in the team. Comments definitely welcome and we can revisit this in the future as needs change.

---

As a largely MLIR-based project, we largely follow LLVM/MLIR design guidelines/coding style/directory structure, etc.

Development is through PRs. Every change should go through a github pull request, in order for pre-commit checks to happen. Most changes should include some sort of unit test. If you can't figure out how to test something, are you really ready to check it in?
Code Formatting is enforced on PRs through clang-format and black. Although these tools change over time, blanket-reformatting of existing code is discouraged.
Code Reviews are not mandated, but are generally encouraged. Code Reviews are expected when modifying core code, or code you're not familiar with, or making significant design changes.
Future work, action items, bugs, etc. should be captured in Github Issues.
Our testing should be sufficient to continuously deliver usable release artifacts (e.g. wheels, tarballs) at any time. We expect other projects to be able to effectively use the release artifacts at any time. Hence, rare changes that somehow break the 'main branch' CI build are expected to be immediately reverted. Changes that break any non-CI build or functionality (e.g. nightlies, out of repo tests, etc.) should be handled through Github 'issues' and the fix should include a CI-based test to avoid future breakage.
'Proper' releases (e.g. something other than a CI artifact) should be handled with an independent release branch, enabling additional fixes to converge a release, while enabling 'normal' development to continue. These fixes should usually be cherry-picked back onto the main branch.