[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: stale MR triaging - you can help!
From:       Albert Astals Cid <aacid () kde ! org>
Date:       2020-10-16 8:00:22
Message-ID: 2335879.NZXjvDDj79 () xps
[Download RAW message or body]

El dimarts, 13 d'octubre de 2020, a les 15:53:10 CEST, Harald Sitter va escriure:
> Moin
> 
> As promised in a previous mail I've set up a system that helps us find
> stale MRs to ensure patches don't fall by the wayside.
> 
> Lists are filed as issues on invent. To help out you can hit the bell to
> subscribe to `New issue` events at
> https://invent.kde.org/sysadmin/gitlab-triaging
> 
> First list of stale MRs here:
> https://invent.kde.org/sysadmin/gitlab-triaging/-/issues
> 
> To deal with a stale MR you'll want to check the box and either make
> sure someone takes a look at the MR (e.g. by @mentioning someone who may
> have experience) or doing the review yourself.
> 
> Unlike previously described I've refined the behavior a bit:
> 
> a) MRs are not linked but listed with verbatim url, it sucks a bit but
> it prevents MRs from updating due to the back-reference an actual
> mention would cause
> b) stale MRs are now MRs that have not seen activity within 4 weeks (up
> from 2 - was woefully too short a time frame)
> c) MRs without subscribers after 2+ weeks are recorded separately
> d) MRs without subscribers after 1+ week where the author is not a KDE
> dev are also recorded (currently a bit bugged as it turns out)
> 
> The motivation with c and d is to prevent MRs from going stale to begin
> with, ideally anyway.

Can we get the issues in each of those 4 categories in different sections of the \
issue you create?

It makes more sense for me to look at d) than at some MR whose author is Aleix (for \
example), if it's stale, he knows how to do how to un-stale it, while a newbie may \
not know how to.

Cheers,
  Albert

> 
> HS
> 


[prev in list] [next in list] [prev in thread] [next in thread]