Git development
 help / color / mirror / Atom feed
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.


  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