Fix typos.

[waywardmonkeys]

No description provided.

[rptb1]

Executing proc.review.entry

1. Entry started 06:29.
2. Change is small and low risk but nobody is available for express review. Plan to batch with other similar changes on 2023-02-23.
3. proc.review.entry.critera: Applying entry.universal.
4. entry.universal.auto-check: check-rst is flagging some errors that are fixed elsewhere.
5. entry.universal.author: Asked @waywardmonkeys for permission via Keybase.
6. Entry passed.
7. Entry took 6 minutes.

[rptb1]

Executing proc.review.plan

1. Start time 06:35.
2. proc.review.plan.size: Change consists mostly of fixing typos in comments, but does include changes to telemetry strings and the monitor that will need a bit of thought. Checking should take no more than 20 minutes.
3. proc.review.plan.roles: @thejayps should proc.review.role.check.correctness of telemetry changes. Other roles will be assigned at kickoff.
4. proc.review.plan.invite: @thejayps , @UNAA008 , and @rptb1 will review on 2023-02-23 11:00.
5. proc.review.plan.rule: rule.generic and rule.style and rule.code
6. Planning took 6 minutes.

[rptb1]

Executing proc.review.kickoff

1. Start time 12:00.
2. Logging 12:10.
3. Kickoff took 1 min because this review is batched with others.

[thejayps]

q: what tool was used to find these, were they found by inspection? If a tool was used it seems useful in that it only seems to search within strings and comments, ignoring variable names.

Im: spelling errors are not regularly searched for by ravenbrook staff (however as the mps project becomes collaborative, this would also become a community responsibility, rather than ravenbrook's). Nonetheless a CI capability or other regularly automated task to scan for spelling errors would be useful

[rptb1]

Executing proc.review.check

1. Start time 12:01
2. IM. tool/monitor does not execute on Ubuntu 22. python3 tool/monitor errors out. There is no reference to how to use it or run it in the leader comment of tool/monitor. Found by considering how the monitor imports the eventdefs.

[UNAA008]

Explicitly checked the changes and agree that the new spellings are correct.

[thejayps]

m: Monitor seems to not be well tested

[rptb1]

Executing proc.review.log

1. Start time 12:11.
2. @UNAA008 found zero. @thejayps found 1m 1q. @rptb1 1M.

Im. @UNAA008 It's undocumented whether we use en-US or en-GB or whatever.

q: what tool was used to find these, were they found by inspection? If a tool was used it seems useful in that it only seems to search within strings and comments, ignoring variable names.

@waywardmonkeys implied in conversation that he found them with his eyes.

IN. @UNAA008 says he often notices typos but too much friction to fix them. I think it's worth considering how we can reduce friction. e.g. weekly-PI branch is an attempt at that.

3. Logging finished 12:21.

[rptb1]

Executing proc.review.brainstorm

1. Start time 12:23.
2. Major defects found today: monitor kinda bust, and review docs seem unrelated to current review process.
3. None of us were really involved in monitor development or review. @UNAA008 remembers some issues about making Python available. @thejayps suspects it's somewhat of a heroic prototype not well productized. One PI would be follow-up on prototypes. @rptb1 It's more that it doesn't say what it is or whether it should work or how or anything really. It's fine if it's a prototype or hard to get running -- but its status is unclear. Writing down proc.review and planning to write down management processes is probably the solution already. @thejayps We need to understand the development story of the monitor so we can work out where to take it. @UNAA008 We must understand the human story as well as the technical development. @rptb1 I think there's a big mistake made by developer often that they dehumanize the process or only think about it in technical terms. proc.review is in fact something where shamelessly deploy human tricks to great effect.
4. @thejayps One idea is to look down on the whole tree of docs and see whether they get led to wrong/old documentation. Very much within Project lacks an introduction for new developers #170 so we'll work on that!
5. Brainstorm end time 12:35.

Just a postscript about the review docs. The "current" review process is still draft on a branch. See #101 .

[rptb1]

There are no edits to the branch, so we're expediting proc.review.exit

1. Start time 13:04.
2. exit.universal.imp is out of date and it's unclear whether improvement suggestions (I) should hold up exit. I'm going to waive that in this case anyway because this is a very small change. I'll mark this pull request as pending so they don't get lost.
3. Revised changed passed. It wasn't revised!
4. review.exit.calc:
   • hours used: 1
   • hours saved: depends on results of monitor work raised, hard to estimate
   • major defects remaining: 0
5. Exit took 5 mins.

[rptb1]

Assigned @UNAA008 to do the merge for practice.

[rptb1]

proc.review.exit.pass

[rptb1]

Executing proc.review.edit

1. Start time 19:18

Im: spelling errors are not regularly searched for by ravenbrook staff (however as the mps project becomes collaborative, this would also become a community responsibility, rather than ravenbrook's). Nonetheless a CI capability or other regularly automated task to scan for spelling errors would be useful

Pass: @thejayps please have a look for a spelling checker that we could apply to the entire MPS tree (copes with source code, reStructuredText, HTML, etc.) and that is easily available (e.g. Python), and for CI purposes, can be trained not to fail all the time for trivial reasons. I think creating a tool and adding CI for this would be a good exercise, if it's feasible. Note: scspell is not it 😄

Im. @UNAA008 It's undocumented whether we use en-US or en-GB or whatever.

Forget: I'll let this come up again if the spell checker gets sorted. Otherwise I think we just tolerate any reasonable English.

IN. @UNAA008 says he often notices typos but too much friction to fix them. I think it's worth considering how we can reduce friction. e.g. weekly-PI branch is an attempt at that.

Answer: Start a git branch for typos. Fix them as you see them. When you have a bunch, submit them like @waywardmonkeys did. An editor integration like Emacs vc-mode makes this very cheap, but investigate whatever tools you need to make it cheap.

2. IM. tool/monitor does not execute on Ubuntu 22. python3 tool/monitor errors out. There is no reference to how to use it or run it in the leader comment of tool/monitor. Found by considering how the monitor imports the eventdefs.

Raise: #174

m: Monitor seems to not be well tested

Raise: #174

2. Editing took 16 mins.
3. This was an unusual edit in that all the edits were outside the source document, hence it is OK to do this after exit. I'll also remove the pending label.

Raise: #174

[waywardmonkeys]

FWIW, I find these by having spell checking in vim and noticing when I scroll through files.

[rptb1]

Executing proc.merge.pull-request.

1. Start time 11:06.
2. There is no job or issue or even a post except "Fix typos" but I think that's sufficient in this case.
3. There is no automated test case. We've had some discussion about spelling checks.
4. Merge took 6 minutes.