Re: Huge commitfest app update upcoming: Tags, Draft CF, Help page, and automated commitfest creat/open/close

On 22/06/2025 16:21, David G. Johnston wrote:
> On Sunday, June 22, 2025, Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>
> On 20.06.25 16:41, David G. Johnston wrote:
>
>     I sense there could be some confusion whether such draft
> patches
>     should go into the regular commit fest or the draft commit
> fest, and
>     then also when they should move between them.
>
> Draft CF patches with “Needs Review” are looking for feedback
> from others or otherwise aid in development for a patch that
> isn’t ready to be committed even if said review turns up
> nothing or is otherwise fully resolved.  Patches in Drafts are
> never marked Ready to Commit, they get moved to Open first.
>
> It will be nice if people spend time providing
> reviews/feedback to patches in Drafts when requested.
>
> It’s purely the author’s judgement on the readiness of the
> patch, whether absent our policy they would mark it ready to
> commit or not.  If they believe it is it should be moved to
> open, if no, it should remain in drafts.  This is mostly like
> what happens today but with a clear delineation between
> reviews to help and reviews to approve commit-ability.
>
> Otherwise, it’s a place where author patches can sit without
> having to be bumped to the next cf every other month and where
> an author patch can be ignored by everyone else not authoring it.
>
>
> I don't know about this.  This could become an ongoing source of
> confusion, without any clear benefit.  Either the draft and the
> "real" commitfest are going to be indistinguishable, because they
> are just two places to look for stuff to review in various phases
> of maturity.  Or the draft commitfest is just not going to get any
> attention, which will be annoying for those who put things there
> hoping to get attention.
>
>
> Yes, more experienced people have to want to help people who can’t
> just get a patch ready to commit on their own.  As opposed to only
> reviewing things they expect to perform the formality of the review to
> make it ready to commit.  The tooling help distinguish those cases if
> used properly.  But people have to choose to do the things it
> encourages/enables.
>
> If one performs a review of a non-draft and it isn’t close to ready,
> encourage the author to move it into drafts as part of a teaching
> moment of how their expectations of done-ness and yours differ.
>
> We aren’t going to get 100% accuracy here but it’s is better
> information that intends to address the complaint that what we had was
> not fit for purpose because the information it provided was
> insufficient.  Tags get even more granular while this provides
> high-level draft/non-draft delineation where drafts don’t have to keep
> being shuffled around.  Review Need still needs review no matter where
> it is.  That doesn’t change.

+1

--

Vik Fearing