DOCUMENT: Standardizing Contributing Flow with PRs - WIP

As previously discussed with @ChristopherA and @gorazdko, we should document the PR opening, reviewing/editing, and merging process. Blockchain Commons does use [Github Flow](https://guides.github.com/introduction/flow/index.html), but often times the PR reviewing process can get cumbersome and/or time-consuming. So, here are some ways to make it work more seamlessly, assuming the contributor is a new contributor:

1. Using [Github CLI](https://cli.github.com/) `gh` [Best IMO]:
* Contributor forks the repository
* Contributor creates an issue in base repository to start the discussion or a [draft PR](https://github.blog/2019-02-14-introducing-draft-pull-requests/) (for the latter, the branch would have to be created first)
* Contributor signs CLA and either issues a separate PR or sends via email to Christopher
* Contributor creates a new feature-branch from `master`
* Contributor works on that branch through atomic, **signed** commits
* Contributor finishes work and issues a PR to `master`, checking the ["allow edits from maintainers" box](https://docs.github.com/en/github/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork#enabling-repository-maintainer-permissions-on-existing-pull-requests)
* Contributor requests review
* Maintainers can do `gh pr checkout ` in CLI to review and work on that PR, also through atomic, signed commits. This alleviates Maintainer from doing a review through comments on the PR which the Contributor would later need to manually edit and adjust for, having then to tell Maintainer the review was made, etc. Basically making it simpler and streamlined
* Maintainers finish reviewing/editing and can just do `git push` for all changes to be pushed to Contributor's fork and therefore to the PR as well
* If non-maintainers would want/need to work on reviewing/editing that PR, they wouldn't have permission to do `git push`. So Contributor would have to invite each non-maintainer to Contributor's fork for them to have the necessary permissions to push directly to that fork and therefore to the PR as well
* After the necessary edits and reviews, Maintainers of the base repository can merge to `master` and delete the feature-branch

2. Using Pure Github Flow
* The seven first steps from number one also work here. What changes is beginning on item number eight. Also, here it doesn't matter much whether the reviewer is a Maintainer or a Non-maintainer, so both will be used interchangeably:
* Maintainer branches off of the PR's Contributor branch through a git clone from Contributor fork and branch into a new branch
* Maintainers then work on their branch through atomic, signed commits
* Maintainer finishes working, issues a PR to Contributor's fork
* Contributor merges Maintainer's PR into his fork, updating his own initial PR into base repository
* Maintainer marks base repository PR as ready for merge
* PR can be merged by Maintainer
* Note: this is basically what has been done in PRs for portuguese translation of LBftCL. IMO it's already an improvement on reviewing with comments and requiring Contributor to edit etc.

In any case, we can rapidly notice how 1 is quicker and easier than 2. But it uses `gh` and requires Contributor to invite non-maintainers to his fork so edits can be streamlined and pushes allowed.

Number 2 doesn't require that, but it does require Contributor to merge a PR into their own fork which effectively creates duplicity in terms of work needed -- merge a PR onto a fork so another PR can be updated, only then to merge that PR onto base repo master. Phew!

But there might also be other ways to go about this.

Thoughts?

Issue で提案されている GitHub CLI と純粋な GitHub Flow の選択肢を、リンクされている GitHub Flow および GitHub CLI のドキュメントと併せて確認してください。プロジェクトが採用するレビューおよび編集プロセスを明確にし、新しい contributor が従えるように、合意した contributor、reviewer、merge の手順を文書化してください。

索引モデルが issue の本文から書いたものです。