Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Discussion topics

Item

Notes

General topics

  • MT – Looking to get a new work laptop. What is process?

    • JW – I think you buy it and then file for reimbursement. I’ll verify this with Karmen.

  • Centralize docs? Could put Interchange user guide in Toolkit, makes for more cohesive explanation.

    • Decision: We’ll keep Interchange user guide in Interchange, give JM direct access for small changes, clear guidelines for medium/large changes.

  • Minimum requirements (can always request review and owner will provide it):

    • Small changes (fix typo, wording change of 10 lines or less) → Feel free to merge directly once status is green

    • Medium changes (meanings change but unambiguous improvement) → Give 3 working days after owner is tagged for review, if time window passes with no review or no “I need more time” message, then merge.

    • Large changes (functionality or significant code change) → Requires review.

PR reviews/other unblockers

  • MT – It’s often ambiguous to determine when I need review/what level of access I have.

  • JW – Would a system of “access levels” to each repo help? Kinda like the requirements above, specified for each repo?

  • MT – That’s a good idea in principle, but it may not even be granular enough for existing situations.

  • JW – Saying “don’t worry about it, just merge your own PRs” is shifting the burden from the maintainer, where the other situation is “wow, this was bad, I’m reverting this merge”

  • MT – The ideal number of reverted PRs is 0. But our target number is nonzero, because otherwise we’re being too cautious.

  • JW – About 1-5% of PRs should be reverted if we’re going at the right speed.

    • MT – Agree

  • JW – I think a revert should be expected to come with reopening the PR and filling out a review with “request changes”.

  • MT – Explaining why a revert happened should be required, at least. I’m not sure this should be encoded in policy.

  • MT – Lots of stuff in the culture works well, but one of our overwhelming problems is maintainer neglect.

  • JW – Figuring out a way to raise things as being urgent without making an undue burden of notification is hard. I kinda had a system for this in our check ins but needing a one-week turnaround isn’t conducive to getting work done.

  • JW – For the next few weeks, I’ll start including a new section in reviews for PRs from people who could have direct merge access. This section will be “did this need review, and how would you know?”

  • JW – Better prioritization might come from:

    • Slack “red phone” channel for “hey maintainer, review this”

      • Good idea, not sure it’s the right fit for now

      • DMs can serve this purpose, no need to raise the stakes by making them public

    • More frequent meetings, purposed solely around PR clearance

      • MT – Let’s do this one

      • (Added a PR clearing meeting on Friday)


Action items

  •  

Decisions