commit - 028ccb39fc93171b6237e6a17f743ac614b3a6cb
commit + 3524325ce33e833a8463f6c1589dff7c8684f040
blob - 55b3a956c4b69b9717ffa525b0e909e27dd57b68
blob + 017419b3cfd99c2d63c131419237bd203fab516d
--- notes
+++ notes
@@ -5,7 +5,7 @@ about bugs. Underlying storage should be in Git, such 
 can clone the repository, run a tool of ours (such as gotwebd?)
 and read and modify issues. Ideally, a simple 'got send' of special
 refs would be enough to update issue data in the main repository.
-Hence the storage format we used must be merge-conflict-free by design.
+Hence the storage format we use must be merge-conflict-free by design.
 
 Blueprint for workflow of a good bug tracker using "user pain":
 https://lostgarden.com/2008/05/20/improving-bug-triage-with-user-pain/
@@ -52,7 +52,7 @@ project space just for themselves, and in the PR conte
 
 2) alice creates a branch in alice.gothub.org/src.git and does some work.
 When ready to send a PR, alice creates a dedicated repository at
-alice.gothub.org/foo.git and either provide anonymous read access or adds
+alice.gothub.org/foo.git and either provides anonymous read access or adds
 read credentials such that bob can access foo.git (recall that gotd doesn't
 support per-reference access rules, only per-repository rules);
 alice can also add notification details for bob to be notified of changes
@@ -65,9 +65,9 @@ bob receives notifications when alice sends changes to
 4) in bob.gothub.org/foo.git, bob can use a web UI to leave review comments
 on diffs and/or the full files, on line-by-line granularity;
 all data pertaining to code review is stored bob's repo within a dedicated
-refernce namespace;
+reference namespace;
 bob can add notification details for alice to be informed of code review
-commments
+comments
 
 5) alices can now react to review comments in two ways: leave comments at the
 code review UI for bob.gothub.org/foo.git (needs some way of authentication);