[FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA

[Michael Niedermayer]

On Thu, Nov 09, 2023 at 06:06:16PM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2023-11-09 17:21:12)
> > On Thu, Nov 09, 2023 at 01:21:13PM +0100, Anton Khirnov wrote:
> > > As far as I can tell, the voter list in the last vote should be the same
> > > as the GA from 2020, except for the extra members whose voting rights
> > > expire after 2 years.
> > > 
> > > Do you dispute that? 
> > 
> > There are at least 3 issues here
> > 
> > * The first and maybe the biggest, is that our vote superviser can reply to
> >   mails within 20min (like in this thread here) but is not replying to a simple
> >   question within days where the list of voters comes from he used and how it
> >   relates to the 2020 GA. It gives one the feeling he has some sort of
> >   difficulty with awnsering that question
> >   you took a guess here and replied, and i appreciate that. But really JB
> >   choose this list and also the one in 2020. Only he can explain where these
> >   lists come from and how they relate.
> 
> JB did explain where the list comes from [1] - it was generated by the
> script that is now in our tree. Nobody disputed it in 2020.
> 
> > * I know for a fact that at least zane was not in the 2020 GA as i talked
> >   with him and i know he did cast a vote in 2023 because again he told me.
> >   So even if you partially apply the rules these lists do not match
> 
> Zane had 30 commits in July 2020, so he SHOULD have been on the list. If
> he wasn't, then it was a mistake in 2020.

the 2020 GA list cannot have been created in July 2020 because there where
votes prior that used it.


> 
> > * The 2nd issue is that there are rules how to change the GA over time
> >   like that after 2 years there needs to a confirmation AND that the
> >   other members represent the "active" developers in the last 36 months.
> >   I can see an argument to leave the 2020 GA untouched and use it as is
> >   I can also see an argument to update it, and exactly this was done in a
> >   vote in 2021 by JB. Now we are here trying the 3rd variant of applying
> >   only half the rules.
> >   But whats more so, we actually are not. What you are doing here is
> >   looking at what happened and trying to rationalize it, trying to find
> >   an explanation for the list. Not stating upfront what this list is
> >   IMO this is not acceptable for a vote. Uhm we found this list, lets see
> >   where that might have come from ....
> 
> To be honest, it very much seems to me that you are trying to bikeshed
> the process to death. Yes, it is imperfect, but that is to be expected
> given we've only used it a few times so far, and the last time was over
> 2 years ago. What we are doing here is trying to clarify the rules so
> that we actually can vote with some regularity.

Is it bikesheding if 2 lists that are supposed to be the same differ in
multiple entries ?

these are lists with roughly 50 entries, now we _know_ 2 people differ
but there where 3 on the extra voters list so really 4 differ almost certainly
thats roughly 10% of the voters are wrong.
Thats not bikesheding IMO. We arent talking about 1 voter in hundreads.

I do want to know what happened here and want to have this not happen
again. if i offend people with that investigation then so be it


> 
> In the vote we just had, option A won its contests against B/C/D by
> 17/7, 23/1, and 17/7, respectively. While it is possible that the list
> used was not entirely correct (also depending on
> the intepretation of the rules), I see no reason to think it was
> incorrect in 10 people, which is what you'd need to have a chance of
> getting a different result.

Its not just this vote, its that we need to understand what happened here
so we can prevent this from happening again

thx
[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Nations do behave wisely once they have exhausted all other alternatives. 
-- Abba Eban
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20231109/20101bd4/attachment.sig>