Sruthi Chandran dijo [Fri, Apr 03, 2026 at 09:56:30PM +0200]:
Do you have any improvements to this process that could help making mini-GRs more manageable?I like the name mini-GRs :)
Ok, often naming a problem is an important step towards developing a solution for it. Congratulations on solving that first step! 😉
I just have some ideas, nothing concrete. Mini-GRs can be within a team or if it concerns the whole project, among all the DDs. Instead of long weeks of GR discussions, we can focus on reaching decision within a week or two of discussion. We can also reduce the requirement for sponsorship for the proposals. If our current voting system is heavy, we can even think of something lighter.
So, in the interest of people (maybe including Sruthi) that are not
familiar with the process, that's the way the Technical Committee performs
their votes: a
call for votes is just a mail to the list+bug once there is consensus an
issue has been debated “enough” for it to be voted upon, such as:
https://lists.debian.org/debian-ctte/2025/10/msg00000.html
They, you can see the options are ranked preferentially, in a format
different to devotee's, but equivalent to it. For the specific vote I
quoted as an example, one of the TC members ranked all “go” options equal
and over “None of the above” (A = B = C > N), while other votes ranked them
all according to their preferences (A > B > C > N; B > A > C > N, etc.)
This does not require digging too deep into implementations if the voter
universe is small (i.e. the TC is <10 people). Of course, with ≤5, probably
even voting as an express step would be moot. How large can this scale
without setting up a program to handle ① validation and ② tallying is
beyond what I want to go into for a simple email, but I think this process
can be adopted by many other teams.
– Gunnar.
signature.asc
Description: PGP signature
