MR Gardening - A discussion, please leave your input!

[Johnny Jazeix]

Le mar. 7 mars 2023 à 00:15, AnnoyingRains <annoyingrain5 at gmail.com> a
écrit :

> > We should never close a MR automatically. Only a maintainer of a project
> or the author itself should close a MR.
>
> I agree with not closing MRs automatically. As I stated in my original
> message, we are no longer planning on doing that, it's not helpful and
> is only destructive.
> The decision to close an MR will be left with the specific project's
> maintainers and the person who opened the MR.
>
> > The decision if a MR should be closed or not is often depending on a
> context (e.g. a MR required another MR to be merged first
> > and it is taking more time than expected, the author is busy with other
> things but will eventually come back to it, ...)
> > and a script is unable to see this.
>
> I would also argue that humans that are not a maintainer of that
> specific project should not close an MR for similar reasons. There is
> a lot here that the gardening team would need to know about every
> project
>
> > for GCompris, we don't have a lot of MR and even if some are old, we
> still plan to take over them at some point (we know which ones are
> unmaintained) so I think it's preferable to not add messages.
>
> We can exclude Gcompris if you feel it is needed, but I am unsure how
> labeling MRs as stale and reminding authors wouldn't be preferable.
>
>
Hi,

It will be considered as noise and ignored. We have two use cases:
* Either the person is following and if a MR is stalling it's because
maintainers don't have enough time to handle it now.
* Either the person is no more following (for multiple reasons) and
maintainers already know it and they plan to handle the MR later.

In both cases, no action will be taken.

As there are not a lot of MR (6), it's an amount we can handle it by
ourselves.
I think what you propose is more important and has more values when there a
lot of MR opened and it's more complicated to handle them (or more
maintainers).²

Cheers,

Johnny


> > but this should probably be done manually
>
> We are planning on doing this manually until all of the issues have
> been ironed out perfectly and we know a foolproof way to ensure
> nothing is ever poked that shouldn't be, which may never happen.
> We will open another discussion before automating anything, due to the
> potential disaster a bug could cause.
>
> > "Hi, I really like this work, do you intent to continue working
> > on it or can I take over" than a generic message that feels fake.
>
> This is great, but not exactly what this inititive is about.
> This is more for reminding people that the MR exists (even had one
> case of "oh! I forgot I made this MR" in my small scale test!), and
> labeling MRs so that contributors feel more free to request taking
> over the project.
> Basically, we cannot really take over every stale MR in the entirety of
> KDE.
>
> - Kye Potter, KDE Gardening
>
>
> On Tue, Mar 7, 2023 at 9:39 AM Albert Astals Cid <aacid at kde.org> wrote:
> >
> > El dilluns, 6 de març de 2023, a les 15:18:42 (CET), Carl Schwan va
> escriure:
> > > Hi,
> > >
> > > We should never close a MR automatically. Only a maintainer of a
> project
> > > or the author itself should close a MR. The decision if a MR should be
> > > closed or not is often depending on a context (e.g. a MR required
> another
> > > MR to be merged first and it is taking more time than expected, the
> > > author is busy with other things but will eventually come back to it,
> ...)
> > > and a script is unable to see this.
> > >
> > > I do not mind poking people semi-regularly (every 6 months or so), but
> again
> > > this should probably be done manually and with a small personalized
> message
> > > for example: "Hi, I really like this work, do you intent to continue
> > > working on it or can I take over" than a generic message that feels
> fake.
> > >
> > > I really hate communicating with robots instead of with humans and I
> really
> > > see the trends of trying to automatize all our interaction with dumb
> robots
> > > and chat bots in our society really worrying.
> > >
> > > If we want to automatize, we should instead try to list the stale MRs
> and
> > > maybe send the list to the mailing list once a month so that people are
> > > reminded about them and take a look at which one they may be able to
> unlock.
> >
> > We already have that, they get posted to
> >  https://invent.kde.org/teams/gardening/gitlab/-/issues
> > weekly.
> >
> > What i forgot is what i did to be notified of it by email ^_^
> >
> > Cheers,
> >   Albert
> >
> > >
> > > Cheers,
> > > Carl
> > >
> > >
> > > ------- Original Message -------
> > >
> > > Le dimanche 5 mars 2023 à 11:13 AM, AnnoyingRains <
> annoyingrain5 at gmail.com>
> > a écrit :
> > > > For a short amount of time now, there have been some small-scale
> > > > trials of replying to old MRs with a reminder, and suggesting that
> the
> > > > author closes the MR if it is either no longer needed or if it needs
> > > > more work and the author does not have time for it.
> > > >
> > > > This has appeared to have a positive impact on the state of KDE
> > > > software from this (albeit limited) trial. Some MRs have had renewed
> > > > interest, others have admitted that they had forgotten that the MR
> > > > even existed.
> > > >
> > > > We did consider closing MRs if there was no activity after our ping
> > > > message. We are no longer planning on doing this, as it is more
> > > > destructive than helpful. All decisions on if a MR should be closed
> > > > will be left with the maintainers and the person who opened the MR.
> > > >
> > > > So, we need a proper discussion about this, should we send these
> > > > reminder messages at all? If so, how old should an MR be before
> > > > sending this reminder? Should closing the MR even be suggested in the
> > > > message?
> > > >
> > > > If your specific project does not play nicely with this programme,
> > > > please let us know and we can add it to the list of exclusions on our
> > > > KDE Community page.
> > > >
> > > > I need your input,
> > > > - Kye Potter, KDE Gardening
> >
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20230307/41e90a7e/attachment.htm>