> Junio C Hamano <gitster@pobox.com> writes:
>> +  A discussion on the list might convince you that your changes are
>> +  not such a good idea, in which case you are expected to explicitly
>> +  retract the topic, to releave the maintainer from having to worry
>> +  about it.

> Finally, maybe a rule of thumb as to how old a topic a topic should get
> before a "staleness" update is provided would be helpful, or maybe that
> is too contextually dependent / would potentially introduce some
> unwanted scheduling contract?
>
> Overall, I think the explicit guidance is helpful.

>
> Hi Michael,
>
> By the way, off-topic:
>
> I noticed that several times your replies didn't carry with a
> "In-Reply-To" header, which made me confused about the threads when
> surfing on the web interface of lore.kernel.org. So also, I cannot pull
> down the complete thread with b4. If possible, you may check your email
> clients, though all email clients suck ;-)
>

> Michael Montalbo <mmontalbo@gmail.com> writes:
> [...]
> > Finally, maybe a rule of thumb as to how old a topic a topic should get
> > before a "staleness" update is provided would be helpful, or maybe that
> > is too contextually dependent / would potentially introduce some
> > unwanted scheduling contract?
> >
> > Overall, I think the explicit guidance is helpful.
> 
> I've been working on streamlining my workflow to manage the "What's
> cooking" report, and writing down guidelines with concrete numbers.
> 
>  * When the discussion seems to reach rough consensus that the
>    latest round looks good for 'next', the topic is immediately
>    marked as "Will merge to 'next'?" in my draft copy (note: I do
>    not want to spam the list with "What's cooking" too often, but it
>    is the document I work from, and it is updated multiple times a
>    day).
> 
>  * After no negative opinions are seen on a topic in "Will merge to
>    'next'?" state for about 36 hours, the topic is marked as "Will
>    merge to 'next'".  I will merge such topics during the next
>    integration cycle (note: I can only have up to two integration
>    cycles per day due to time constraints).
> 
>  * Imagine that a topic was last updated more than 4 weeks ago.  If
>    there are review comments on the topic that are left unanswered
>    by the author for more than a week, and if nothing happens in the
>    discussion thread other than inquiry on the current status, the
>    topic is marked as "stalled".  I will try to notice and ping a
>    stalled topic once or twice, but after that I may discard such a
>    topic (which by the way I really hate having to decide to do so).
> 
>  * After a topic is merged to 'next', if nothing negative that needs
>    fixing is discovered for 7 calendar days, the topic is merged to
>    'master'.  I may shorten this depending on how complex the topic
>    is.
> 
> There may be more, but these are what I can think of offhand.

> I think my workflow for replying to threads I am not already a part of is
> flawed. I usually control-click the reply mailto: link on the message in
> lore.kernel.org/git. That launches Gmail then I manually craft a message
> and send from there. I will spend some time investigating my workflow
> more deeply.

> On Tue, Jul 07, 2026 at 09:52:14PM -0700, Junio C Hamano wrote:
>> Michael Montalbo <mmontalbo@gmail.com> writes:
>> [...]
>> > Finally, maybe a rule of thumb as to how old a topic a topic should get
>> > before a "staleness" update is provided would be helpful, or maybe that
>> > is too contextually dependent / would potentially introduce some
>> > unwanted scheduling contract?
>> >
>> > Overall, I think the explicit guidance is helpful.
>> 
>> I've been working on streamlining my workflow to manage the "What's
>> cooking" report, and writing down guidelines with concrete numbers.
>> 
>>  * When the discussion seems to reach rough consensus that the
>>    latest round looks good for 'next', the topic is immediately
>>    marked as "Will merge to 'next'?" in my draft copy (note: I do
>>    not want to spam the list with "What's cooking" too often, but it
>>    is the document I work from, and it is updated multiple times a
>>    day).
>> 
>>  * After no negative opinions are seen on a topic in "Will merge to
>>    'next'?" state for about 36 hours, the topic is marked as "Will
>>    merge to 'next'".  I will merge such topics during the next
>>    integration cycle (note: I can only have up to two integration
>>    cycles per day due to time constraints).
>> 
>>  * Imagine that a topic was last updated more than 4 weeks ago.  If
>>    there are review comments on the topic that are left unanswered
>>    by the author for more than a week, and if nothing happens in the
>>    discussion thread other than inquiry on the current status, the
>>    topic is marked as "stalled".  I will try to notice and ping a
>>    stalled topic once or twice, but after that I may discard such a
>>    topic (which by the way I really hate having to decide to do so).
>> 
>>  * After a topic is merged to 'next', if nothing negative that needs
>>    fixing is discovered for 7 calendar days, the topic is merged to
>>    'master'.  I may shorten this depending on how complex the topic
>>    is.
>> 
>> There may be more, but these are what I can think of offhand.
>
> Integrating the above parts into the document seems like a good idea.

> btw, do we need to synchronize MyFirstContribution simultaneously?
>
> Quoting Patrick's words [1]:
>
> Overall it's a bit on the annoying side that we have to always make sure
> to update both SubmittingPatches and MyFirstContribution in tandem.
> Makes me wonder whether they are mostly redundant and whether it would
> make sense to eventually merge them.