Re: [PATCH] doc: add tutorial on branches for beginners

["Julia Evans" <julia@jvns.ca>]

On Mon, Nov 9, 2026, at 5:11 PM, Junio C Hamano wrote:
> "Julia Evans" <julia@jvns.ca> writes:
>
>>> I wonder what incentives, carrots and sticks we have on those who
>>> have in-flight topics that are so close to the finish line to
>>> concentrate on completing these topics before sending new ones.
>>>
>>> Ideas?
>>
>> For sure, I can avoid submitting new topics in the future until the
>> current ones are finished. I don't have any other changes in progress
>> in any case. 
>>
>> I'm very conscious that reviewer bandwidth is limited and I'm very
>> interested in ideas for how to make the docs review process easier.
>
> My interest in making review process better is not limited to
> documentation patches, though.

When I applied for funding from the Sovereign Tech Agency to work on
the Git project's documentation, the main risk I flagged in my application
was that reviewer capacity in the project is very limited. I tried to deal with
this in a several ways:

1. I emailed a few people who had reviewed my patches in the past to ask
if they would be have capacity to do review on the new patches.
Patrick and Ben agreed to do some reviews which I really appreciate.
2. I applied for a relatively small amount of funding, which limits how
many hours Marie and I actually spent writing. Fewer hours spent writing
means less work to review :)
3. We recruited dozens of test readers to participate in a kind of side
review process. That doesn't serve the same function as the mailing list
review of course, but it hugely improves the final quality of the document
without introducing extra pressure on Git project's reviewers.

I don't know which of these strategies would apply to code changes but
those are some of things I've tried so far.