<div dir="ltr"><div dir="ltr"></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mar. 7 mars 2023 à 00:15, AnnoyingRains <<a href="mailto:annoyingrain5@gmail.com">annoyingrain5@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> We should never close a MR automatically. Only a maintainer of a project or the author itself should close a MR.<br>
<br>
I agree with not closing MRs automatically. As I stated in my original<br>
message, we are no longer planning on doing that, it's not helpful and<br>
is only destructive.<br>
The decision to close an MR will be left with the specific project's<br>
maintainers and the person who opened the MR.<br>
<br></blockquote><div>I would argue we should allow some degree of automated closing.</div><div>Maintainers' time is precious, requiring maintainers to follow up every opened MRs in addition to the bugs and their own dev work is excessive.</div><div><br></div><div>Contributors should be warned and have a say, but when they don't react, what to do then ?</div><div>That's something that happens for dolphin or Kio, cases I know.</div><div>Plus the longer the stale guests the more bit-rot the code gets.<br></div><div><br></div><div>Every MRs gets either merged given enough time, or abandoned by its author(s).</div><div>We can't expect every contributor to finish their MR and especially months or years later.</div><div>Some will, some won't.</div><div>I guess projects could have different needs, but it seems to me a large auto-close threshold of 18 or 24 months or so would hardly do any harm.<br></div><div><br></div><div>We could use a "stale" label for MR to allow maintainers to see the script's results.</div><div>And even a "closing-soon" label, for MR not-update in the last 12 months.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> 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<br>
> and it is taking more time than expected, the author is busy with other things but will eventually come back to it, ...)<br>
> and a script is unable to see this.<br>
<br>
I would also argue that humans that are not a maintainer of that<br>
specific project should not close an MR for similar reasons. There is<br>
a lot here that the gardening team would need to know about every<br>
project<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> 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.<br>
<br>
We can exclude Gcompris if you feel it is needed, but I am unsure how<br>
labeling MRs as stale and reminding authors wouldn't be preferable.<br>
<br>
> but this should probably be done manually<br>
<br>
We are planning on doing this manually until all of the issues have<br>
been ironed out perfectly and we know a foolproof way to ensure<br>
nothing is ever poked that shouldn't be, which may never happen.<br>
We will open another discussion before automating anything, due to the<br>
potential disaster a bug could cause.<br>
<br>
> "Hi, I really like this work, do you intent to continue working<br>
> on it or can I take over" than a generic message that feels fake.<br>
<br>
This is great, but not exactly what this inititive is about.<br>
This is more for reminding people that the MR exists (even had one<br>
case of "oh! I forgot I made this MR" in my small scale test!), and<br>
labeling MRs so that contributors feel more free to request taking<br>
over the project.<br>
Basically, we cannot really take over every stale MR in the entirety of KDE.<br>
<br>
- Kye Potter, KDE Gardening<br>
<br>
<br>
On Tue, Mar 7, 2023 at 9:39 AM Albert Astals Cid <<a href="mailto:aacid@kde.org" target="_blank">aacid@kde.org</a>> wrote:<br>
><br>
> El dilluns, 6 de març de 2023, a les 15:18:42 (CET), Carl Schwan va escriure:<br>
> > Hi,<br>
> ><br>
> > We should never close a MR automatically. Only a maintainer of a project<br>
> > or the author itself should close a MR. The decision if a MR should be<br>
> > closed or not is often depending on a context (e.g. a MR required another<br>
> > MR to be merged first and it is taking more time than expected, the<br>
> > author is busy with other things but will eventually come back to it, ...)<br>
> > and a script is unable to see this.<br>
> ><br>
> > I do not mind poking people semi-regularly (every 6 months or so), but again<br>
> > this should probably be done manually and with a small personalized message<br>
> > for example: "Hi, I really like this work, do you intent to continue<br>
> > working on it or can I take over" than a generic message that feels fake.<br>
> ><br>
> > I really hate communicating with robots instead of with humans and I really<br>
> > see the trends of trying to automatize all our interaction with dumb robots<br>
> > and chat bots in our society really worrying.<br>
> ><br>
> > If we want to automatize, we should instead try to list the stale MRs and<br>
> > maybe send the list to the mailing list once a month so that people are<br>
> > reminded about them and take a look at which one they may be able to unlock.<br>
><br>
> We already have that, they get posted to<br>
>  <a href="https://invent.kde.org/teams/gardening/gitlab/-/issues" rel="noreferrer" target="_blank">https://invent.kde.org/teams/gardening/gitlab/-/issues</a><br>
> weekly.<br></blockquote><div><br></div><div>This listing is great, could we add a label "stale" to the MR concerned so that's explicit for maintainers.</div></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Méven</div></div>