Blog for Public Code

This blogpost

Feed

Subscription feed

7 September 2022 Standard for Public Code community call

Attendees

Updates from the Foundation

Background

In Require review of contributions we have the requirement:

Reviews SHOULD happen within two business days.

But this is ambiguous in terms of what it means. Should it be finished within two days or just started? Some reviews will reasonably take longer because of the size and complexity of the contribution. How can we make this less ambiguous, but also not encourage reviews that have been started but are not meaningful (compare to the British “Hello nurses”)? See issue #908.

Notes

We first noted that having a service level agreement that has a development vendor on standby to review contributions in two business days might be costly. As some codebases are in heavier development than others and might have developers at hand, could the requirement be differentiated somehow? While the concern about cost is real, with the recently added requirement in Welcome contributors:

The contribution guidelines SHOULD document who is expected to cover the costs of reviewing contributions.

it should be clear that it may not be the one reviewing that should pay for it. This means that the Standard allows for different situations already and if all review is outsourced, the cost for that could be on the party making a contribution. We also noted that the criterion Use continuous integration has the requirement:

The codebase MUST have active contributors who can review contributions.

and thus there must be a way for reviews to be able to take place, even if the development pace is low.

Second, we considered that most reviews easily can happen within two business days and only occasionally will something be so big or complex that review will have to take longer time. After pondering a distribution model, we realized that this is a SHOULD requirement, and that might give the leeway needed. That is, when testing this, the codebase stewards would check the review times, and for those reviews taking longer than two days, the senior developers should have a plausible, and preferably documented, explanation for the long review time.

The idea is therefore to add to the How to test section how this would be done by the codebase stewards in order to provide transparency.

We briefly discussed the existence of tools that could help surface contributions needing closer inspection and realized that even if no ready one exists, it should be possible to develop a simple tool that can filter well enough to reduce the manual inspection to a manageable size.