From: Phillip Wood <phillip.wood123@gmail.com>
To: Junio C Hamano <gitster@pobox.com>, Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org
Subject: Re: Ejecting things more aggressively out of 'seen'?
Date: Mon, 2 Nov 2026 16:34:23 +0000 [thread overview]
Message-ID: <48a6c039-75b6-4fa4-a18e-ea3240037be9@gmail.com> (raw)
In-Reply-To: <xmqqv76fjjhg.fsf@gitster.g>
On 02/11/2026 16:17, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
>
>> One state that confuses newcomers quite often is "Will merge to 'next'?"
>> with a question mark at the end. If we were to document these we shuld
>> probably also document that state.
>
> Hmph, really? Just like the subject of this e-mail message, a
> trailing question mark is my way of saying "I am planning to do
> this, but if you think it is a bad idea, please stop me with an
> explanation why I shouldn't".
The subject of this message feels more like a question, whereas it
sounds like "Will merge to next?" means "I'm going to do that unless
someone stops me" rather than "do others think this is ready for next?"
>>> - A topic goes into the "Waiting for response" state once reviewed,
>>> where it remains until the author responds. After staying in
>>> this state for a month or so, it is demoted to the "Stalled"
>>> state, and eventually dropped.
>>>
>>> We should probably have a rule that says "a topic that did not get
>>> reviewed for N weeks is ejected from 'seen'".
>>
>> I think that's reasonable. Becoming a bit more aggressive there doesn't
>> make too much of a difference anyway -- if a topic gets evicted from
>> "seen" and then later on regains interest then it can still be included
>> into "seen" again.
Indeed
>> By gut feeling I'd use the same rule as for "Waiting for response".
Perhaps making it clear that when a topic is ejected it can be re-added
if there is renewed interest in it would lessen any worry about
demotivating contributors?
Thanks
Phillip
> An obvious alternative is to queue only topics for which I can, by
> judging reviews on the list, at least say "Will merge to 'next'?"
> with enough confidence. It would reduce the size of 'seen' and the
> friction felt by contributors when their topic is once queued on
> 'seen' and later ejected unceremoniously through no fault of their
> own, other than their topic being forgettable or uninspiring to
> others.
>
> I do not know which one is better: educating contributors that their
> topics being uninspiring to others is something they should not feel
> bad about and giving our reviewers easier access to these candidate
> topics, or being strict and mechanical and queuing only topics that
> some human reviewers with a certain level of reputation have looked
> at and have not just shown interest in, but have said are ready.
>
> I can do either. It is less emotional stress for me to do the
> latter. Between hitting 'seen' and then later being discarded, and
> not getting any response or reaction at all, I am not sure which one
> our contributors find more acceptable.
next prev parent reply other threads:[~2026-11-02 16:34 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-27 3:09 What's cooking in git.git (Jul 2026, #12) Junio C Hamano
2026-07-29 13:24 ` Phillip Wood
2026-07-29 14:18 ` Junio C Hamano
2026-07-29 15:20 ` Phillip Wood
2026-07-29 17:48 ` Junio C Hamano
2026-08-05 13:10 ` Phillip Wood
2026-08-05 17:03 ` Junio C Hamano
2026-11-02 7:31 ` Ejecting things more aggressively out of 'seen'? Junio C Hamano
2026-11-02 9:59 ` Patrick Steinhardt
2026-11-02 16:17 ` Junio C Hamano
2026-11-02 16:34 ` Phillip Wood [this message]
2026-07-31 6:20 ` What's cooking in git.git (Jul 2026, #12) Matt Hunter
2026-07-31 15:36 ` Junio C Hamano
2026-07-30 6:11 ` Harald Nordgren
2026-07-31 7:02 ` Matt Hunter
2026-08-03 9:05 ` Phillip Wood
2026-08-03 16:02 ` Junio C Hamano
2026-08-04 13:19 ` Phillip Wood
2026-08-03 9:11 ` Phillip Wood
2026-07-29 15:14 ` Phillip Wood
2026-07-29 15:52 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48a6c039-75b6-4fa4-a18e-ea3240037be9@gmail.com \
--to=phillip.wood123@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=phillip.wood@dunelm.org.uk \
--cc=ps@pks.im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox