Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
Derek Buitenhuis writes: > On 11/20/2023 3:44 PM, Thilo Borgmann via ffmpeg-devel wrote: >> the results are available at [1]. As they confirm the just updated GA list >> as >> well as the update procedure twice a year on Jan 1st & Jul 1st, I think the >> upcoming votes (extra GA members, TC/CC elections) can then proceed as >> announced. > > The vote was not valid and announcing them like this is misleading. > > - Derek Here's a link to the original vote results: https://vote.ffmpeg.org/cgi-bin/civs/results.pl?id=E_029f7195fed7aadf Yes, 'redoing' the vote is completely questionable; yes, even I objected to it personally. And whilst we don't know how reliable the 2nd vote was, the outcome is still the same as the original vote: this means that it is possible to both discard the 2nd vote and prefer it (depending on your perspective). Some previous mails quoted me on IRC but seemed to omit essential information, so I will repeat it here on the mailing list. The original voter list was made in a few minutes by myself and the exact copy was lost to time, I found different versions looking through my mails sent and it's pretty unreliable. Saving the git hash and a date was something added later. However, none of this is really relevant since all we really need is a general consensus to update the GA list using the script--from which we are able to have a traceable list of voters and stop worrying about this. In short: We should be able to move forward now. -- jd ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
On 11/20/2023 3:44 PM, Thilo Borgmann via ffmpeg-devel wrote: > the results are available at [1]. As they confirm the just updated GA list as > well as the update procedure twice a year on Jan 1st & Jul 1st, I think the > upcoming votes (extra GA members, TC/CC elections) can then proceed as > announced. The vote was not valid and announcing them like this is misleading. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
Hi, This vote will be repeated from Sun 12th of November to Sunday 19th of November so we don't have to move the following votes yet another time. It will be using the list given by Josh [2] as it seems to be the closest to the truth we can get. The old extra members of the GA have become void according to [4] and will not be included. the results are available at [1]. As they confirm the just updated GA list as well as the update procedure twice a year on Jan 1st & Jul 1st, I think the upcoming votes (extra GA members, TC/CC elections) can then proceed as announced. -Thilo [1] https://vote.ffmpeg.org/cgi-bin/civs/results.pl?id=E_07e9c717f7820201 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
tis 2023-11-14 klockan 18:46 +0200 skrev Rémi Denis-Courmont: > Le tiistaina 14. marraskuuta 2023, 17.56.24 EET Tomas Härdin a écrit > : > > Ballots should be public IMO, secret voting is cowardice. > > The French (XIXth century) Empire used notoriously public ballots, > and the > results were skewed to say the least. There is a good reason why > ballots are > supposed to be confidential. > > And I don't think FFmpeg is immune to the same sort of issues. > Consider the > case of developers with any kind of corporate affiliation or > financial > dependency. What's to prevent their boss from telling them how to > vote if the > ballots are public? Secret ballots do not prevent this. The only method we know that works is voting in person with pen and paper. It's honestly surprising how much trust is given to e-voting by people of which I assume a majority have CS degrees. /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
Rémi Denis-Courmont (12023-11-14): > Like for example, people could give votes to associates of the leading > contracting company of FFmpeg at the given time in hope of looking good to > get > subcontracted later. Or all legal VideoLAN members feeling morally obliged to > vote for other VideoLAN members (and they are quite of us in the FFmpeg GA). Hum. This is an angle I had neglected, thanks for bringing it up. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
On 14 Nov 2023, at 20:32, Ronald S. Bultje wrote: > On Tue, Nov 14, 2023 at 2:28 PM Nicolas George wrote: > >> but nobody here knows >> > > Unsubstantiated FUD. > > Move on. +1 There is no good in even more discussions right now. If really many people think public ballots are a great idea, this can be brought up later in the GA again, after all the other votes that need to be done right now are over… > > Ronald > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
On Tue, Nov 14, 2023 at 2:28 PM Nicolas George wrote: > I hope you can grasp the difference between CAN and WOULD. That would be > better than calling somebody's logical arguments “FUD”. > You're right, we should call things by their name, these arguments are illogical. -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
On Tue, Nov 14, 2023 at 2:28 PM Nicolas George wrote: > but nobody here knows > Unsubstantiated FUD. Move on. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
Ronald S. Bultje (12023-11-14): > > Nothing prevents their boss from telling them how to vote, even if the > > ballots are secret. > How is this not just unsubstantiated FUD? Because it is just plain logical truth: somebody's boss CAN do what I described in the part of my mail that you just snipped. That is a simple fact. (Try arguing against it…) Whether any particular somebody's WOULD actually do it… depends on the boss. Some are definitely not above that at all, but nobody here knows if they are around the FFmpeg project. I hope you can grasp the difference between CAN and WOULD. That would be better than calling somebody's logical arguments “FUD”. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
Hi, On Tue, Nov 14, 2023 at 1:44 PM Nicolas George wrote: > Nothing prevents their boss from telling them how to vote, even if the > ballots are secret. > How is this not just unsubstantiated FUD? We're discussing concerns that are randomly thrown in without evidence that they're relevant or real. I think that we should protect FFmpeg's GA from alien invasions. And I want a pony. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
Le tiistaina 14. marraskuuta 2023, 20.44.18 EET Nicolas George a écrit : > Nothing prevents their boss from telling them how to vote, even if the > ballots are secret. Ultimately, nothing prevents their boss from literally telling them how to vote. But obviously unless the boss is actively monitoring their screen whilst they vote, they won't know what they voted for. That's a huge difference from public ballot. And the literal boss is just the "extreme" case. But if ballots are public, some people will naturally be inclined to vote for those that they want to cure favour from, rather than whom they think is best fit for the role. Like for example, people could give votes to associates of the leading contracting company of FFmpeg at the given time in hope of looking good to get subcontracted later. Or all legal VideoLAN members feeling morally obliged to vote for other VideoLAN members (and they are quite of us in the FFmpeg GA). I know you would be the last to do that sort of thing, but you are not the only voter. -- 雷米‧德尼-库尔蒙 http://www.remlab.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
Rémi Denis-Courmont (12023-11-14): > The French (XIXth century) Empire used notoriously public ballots, and the > results were skewed to say the least. There is a good reason why ballots are > supposed to be confidential. > > And I don't think FFmpeg is immune to the same sort of issues. Consider the > case of developers with any kind of corporate affiliation or financial > dependency. What's to prevent their boss from telling them how to vote if the > ballots are public? Nothing prevents their boss from telling them how to vote, even if the ballots are secret. The kind of secrecy a remote voting software can give us is “urn-style” secrecy: once the ballot is in the box, now way of knowing whose ballot it is. But to prevent bosses from interfering, we would need “voting-booth-style” secrecy: secrecy as the ballot is being cast and no way for the person who cast it to prove what they voted for. Vote-from-home systems cannot provide voting-booth-style secrecy: somebody can hover behind your back while you cast your ballot, or even demand you surrender your secret token. Urn-style secrecy, the only kind we can have, only protects from casual interference, like a kind in a conservative family not daring vote liberal, or an elected official voting against the interests of their biggest campaign donors. This is obviously not a problem for a libre software projects where contributors are all over the world and barely know each others. Now that the question has been raised and I had a chance to reflect on it, I think votes should probably be public. For votes about technical questions, it seems to me quite obvious. For votes about people, like the one now, it is more doubtful because it can lead to more personal polarization, but I am rather in favor too. Also, I will say it here instead of sending a separate mail: I find the strategy of legal intimidation about the GDPR disgusting. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
Le tiistaina 14. marraskuuta 2023, 17.56.24 EET Tomas Härdin a écrit : > Ballots should be public IMO, secret voting is cowardice. The French (XIXth century) Empire used notoriously public ballots, and the results were skewed to say the least. There is a good reason why ballots are supposed to be confidential. And I don't think FFmpeg is immune to the same sort of issues. Consider the case of developers with any kind of corporate affiliation or financial dependency. What's to prevent their boss from telling them how to vote if the ballots are public? -- レミ・デニ-クールモン http://www.remlab.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
On Tue, Nov 14, 2023 at 10:56 AM Tomas Härdin wrote: > Ballot secrecy cannot actually be guaranteed. While I'm not versed in > the specifics of CIVS, I doubt it has solved problems like evil > sysadmin. Ballots should be public IMO, secret voting is cowardice. > That way duplicate ballots are easily filtered out ex-post and > scrutable to all. > Absolutely not, you're mixing cowardice for safety and privacy, especially in a community that is prone to toxic language and harassment. Further reading https://www.rochester.edu/newscenter/should-secret-voting-be-mandatory-yes-say-political-scientists-459082/ https://www.quora.com/Should-voting-be-public-so-that-everyone-one-knows-what-everyone-else-voted-for-instead-of-secret https://daily.jstor.org/why-do-we-vote-by-secret-ballot/ https://campaignlegal.org/update/voters-have-right-secret-ballot https://www.quora.com/Why-is-it-important-for-votes-to-be-secret What really matters is records for every vote, and automatic random audits, so that results can be reproduced. -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
tis 2023-11-14 klockan 13:49 +0100 skrev Thilo Borgmann via ffmpeg- devel: > Am 14.11.23 um 10:28 schrieb Tomas Härdin: > > lör 2023-11-11 klockan 10:42 +0100 skrev Jean-Baptiste Kempf: > > > > > > You have been told, now, several times, that a list of email is a > > > collection of Private Information, according to a GDPR and that > > > you > > > are a process of this PI, and therefore liable to the law. > > > > Everyone with a copy of the git repository already has this > > information, and it has been willingly given by all contributors. > > Is > > further processing of already extant PI really not permissible > > according to the GDPR? Do we have to seek permission from all > > contributors to publish our git repositories containing PI that > > they > > have already given implicit permission to publish? > > +1 that it is no problem to reshare public information. > A problem would arise if we connect this information with other > information - new unknown information or an unknown link between the > two. Makes sense to me. > > That said, this part strikes me as far more relevant wrt the GDPR: > > > > > I patched the voting system to log all authorized voters in the > > > future to prevent this situation in the future. > > The logfile before: > > Sun Nov 5 11:04:32 2023 127.0.0.1 Sending mail to a voter for poll > E_af2d343f39602862 > Sun Nov 5 11:04:32 2023 127.0.0.1 Sending mail to a voter for poll > E_af2d343f39602862 > > The logfile afterwards: > > Sun Nov 5 11:04:32 2023 127.0.0.1 Sending mail to a voter for poll > E_af2d343f39602862 someth...@somewhere.com > Sun Nov 5 11:04:32 2023 127.0.0.1 Sending mail to a voter for poll > E_af2d343f39602862 somethinge...@somewhereelse.com > > The other outputs are unchanged. > This does not break any privacy about the ballots - it is still > unknown what ballots voted if at all neither what that ballot > eventually voted for. Ballot secrecy cannot actually be guaranteed. While I'm not versed in the specifics of CIVS, I doubt it has solved problems like evil sysadmin. Ballots should be public IMO, secret voting is cowardice. That way duplicate ballots are easily filtered out ex-post and scrutable to all. /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
Am 14.11.23 um 10:28 schrieb Tomas Härdin: lör 2023-11-11 klockan 10:42 +0100 skrev Jean-Baptiste Kempf: You have been told, now, several times, that a list of email is a collection of Private Information, according to a GDPR and that you are a process of this PI, and therefore liable to the law. Everyone with a copy of the git repository already has this information, and it has been willingly given by all contributors. Is further processing of already extant PI really not permissible according to the GDPR? Do we have to seek permission from all contributors to publish our git repositories containing PI that they have already given implicit permission to publish? +1 that it is no problem to reshare public information. A problem would arise if we connect this information with other information - new unknown information or an unknown link between the two. That said, this part strikes me as far more relevant wrt the GDPR: I patched the voting system to log all authorized voters in the future to prevent this situation in the future. The logfile before: Sun Nov 5 11:04:32 2023 127.0.0.1 Sending mail to a voter for poll E_af2d343f39602862 Sun Nov 5 11:04:32 2023 127.0.0.1 Sending mail to a voter for poll E_af2d343f39602862 The logfile afterwards: Sun Nov 5 11:04:32 2023 127.0.0.1 Sending mail to a voter for poll E_af2d343f39602862 someth...@somewhere.com Sun Nov 5 11:04:32 2023 127.0.0.1 Sending mail to a voter for poll E_af2d343f39602862 somethinge...@somewhereelse.com The other outputs are unchanged. This does not break any privacy about the ballots - it is still unknown what ballots voted if at all neither what that ballot eventually voted for. This only adds the information which mail addresses are connected to the poll ID E_* (in other words, who was an authorized voter). -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
lör 2023-11-11 klockan 10:42 +0100 skrev Jean-Baptiste Kempf: > > You have been told, now, several times, that a list of email is a > collection of Private Information, according to a GDPR and that you > are a process of this PI, and therefore liable to the law. Everyone with a copy of the git repository already has this information, and it has been willingly given by all contributors. Is further processing of already extant PI really not permissible according to the GDPR? Do we have to seek permission from all contributors to publish our git repositories containing PI that they have already given implicit permission to publish? That said, this part strikes me as far more relevant wrt the GDPR: > I patched the voting system to log all authorized voters in the > future to prevent this situation in the future. /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
On Sun, Nov 12, 2023 at 07:34:07PM +0100, Anton Khirnov wrote: > Quoting Michael Niedermayer (2023-11-12 19:02:31) > > On Sun, Nov 12, 2023 at 06:43:28PM +0100, J. Dekker wrote: > > > On Sun, Nov 12, 2023, at 18:31, Michael Niedermayer wrote: > > > > On Sun, Nov 12, 2023 at 11:03:21AM -0300, James Almer wrote: > > > >> On 11/12/2023 10:59 AM, Thilo Borgmann via ffmpeg-devel wrote: > > > >> > I will also start the repeat vote now and everybody can hold their > > > >> > horses before going to flamewar. Depending on JB's explanations, he > > > >> > might still prove that the old vote is valid and this repeat vote > > > >> > becomes void. > > > >> > > > >> Or you could have waited for his answer before doing the vote, don't > > > >> you > > > >> think? Now people got a new vote email that may or may not be valid at > > > >> all. > > > > > > > > I hope this new vote will result in the same winner as the last > > > > because otherwise we will have more questions and accusations > > > > > > Multiple people (including myself) have already posted their voting URLs > > > publicly > > > so this 'vote' outcome will be extremely questionable at best. > > > > i saw it. > > I guess its your right to protest that way, its your ballot > > > > its a bit unfortunate. > > i have not really finished investigating what exactly happened in the > > previous vote, but more information is still trickling in. > > There where mistakes made in the previous vote though i doubt they > > affected the outcome, but i do not know > > There were mistakes made in this "vote" as well. Even disregarding the > question of its legitimacy, Thilo's list had two duplicates. After > removing them (which it's not clear whether Thilo did - so much for > transparency), it was identical to JB's list except for Thilo's having > three fewer entries. > > One is Gautam, who AFAICT has not had any contact with the project > since 2020. > > One is Ting Fu, whose Intel mailbox no longer exists, and so his > presence or absence on the list does not matter as he cannot receive the > voting link. > > One is Thilo himself, who was added to the list after his assertion that > he voted in 2020 and so should vote now [1]. In other words, he asked to be > added to the list and then used his presence on it to argue that the > list is invalid. Draw your own conclusions about this. > > Overall I simply do not see how is stoking the flames and feeding the > drama supposed to help the project. The main issue is that we, as a > project, failed in 2020 to make the process sufficiently clear, so any > voter list can be questioned. Thankfully it does not matter, because the > result of the vote was so overwhelmingly in favor of one option, that > none of the proposed alternative lists could possibly change it. > > I would thus propose to end wasting time on meaningless arguments and > move on to something actually productive, like reviews, patches, and the > rest of the two proposed votes. i agree i still am working on my investigation of the previous vote and i think i want to show this to a few people before posting it here so it gets a bit peer review first. (also i dont want to post it deeply in a random thread as noone will find that again) (its a very simple terse list ATM) I see through your list above that you are qualified to review this so i will send it to you :) > > > I think anton, thilo and jb should have paused the votes and waited > > until we fully understand the previous votes issues. > > now it becomes only more messy > > previous vote, repeat vote, some agree some disagree thats the right path > > next votes following on top of ? > > some calls to changes to vote admin, some calls to change vote superviser > > some calls to change server > > > > in a week we have 8 servers 16 vote admins 32 vote supervisers and 64 > > different outcomes of the previous vote > > > > we can get rich by renting out all that vote infra we soon will have ;) > > The only reason to have our own vote server in the first place was that > the one run by its author [2] did not implement proportional > representation at the time. That has now changed, so I propose we simply > switch to it. Thilo has fixed the email loging after the last vote. So from now on we will know exactly who get a vote email. This is a big advantage to avoid the sort of mess we have ATM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Elect your leaders based on what they did after the last election, not based on what they say before an election. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
Quoting Michael Niedermayer (2023-11-12 19:02:31) > On Sun, Nov 12, 2023 at 06:43:28PM +0100, J. Dekker wrote: > > On Sun, Nov 12, 2023, at 18:31, Michael Niedermayer wrote: > > > On Sun, Nov 12, 2023 at 11:03:21AM -0300, James Almer wrote: > > >> On 11/12/2023 10:59 AM, Thilo Borgmann via ffmpeg-devel wrote: > > >> > I will also start the repeat vote now and everybody can hold their > > >> > horses before going to flamewar. Depending on JB's explanations, he > > >> > might still prove that the old vote is valid and this repeat vote > > >> > becomes void. > > >> > > >> Or you could have waited for his answer before doing the vote, don't you > > >> think? Now people got a new vote email that may or may not be valid at > > >> all. > > > > > > I hope this new vote will result in the same winner as the last > > > because otherwise we will have more questions and accusations > > > > Multiple people (including myself) have already posted their voting URLs > > publicly > > so this 'vote' outcome will be extremely questionable at best. > > i saw it. > I guess its your right to protest that way, its your ballot > > its a bit unfortunate. > i have not really finished investigating what exactly happened in the > previous vote, but more information is still trickling in. > There where mistakes made in the previous vote though i doubt they > affected the outcome, but i do not know There were mistakes made in this "vote" as well. Even disregarding the question of its legitimacy, Thilo's list had two duplicates. After removing them (which it's not clear whether Thilo did - so much for transparency), it was identical to JB's list except for Thilo's having three fewer entries. One is Gautam, who AFAICT has not had any contact with the project since 2020. One is Ting Fu, whose Intel mailbox no longer exists, and so his presence or absence on the list does not matter as he cannot receive the voting link. One is Thilo himself, who was added to the list after his assertion that he voted in 2020 and so should vote now [1]. In other words, he asked to be added to the list and then used his presence on it to argue that the list is invalid. Draw your own conclusions about this. Overall I simply do not see how is stoking the flames and feeding the drama supposed to help the project. The main issue is that we, as a project, failed in 2020 to make the process sufficiently clear, so any voter list can be questioned. Thankfully it does not matter, because the result of the vote was so overwhelmingly in favor of one option, that none of the proposed alternative lists could possibly change it. I would thus propose to end wasting time on meaningless arguments and move on to something actually productive, like reviews, patches, and the rest of the two proposed votes. > I think anton, thilo and jb should have paused the votes and waited > until we fully understand the previous votes issues. > now it becomes only more messy > previous vote, repeat vote, some agree some disagree thats the right path > next votes following on top of ? > some calls to changes to vote admin, some calls to change vote superviser > some calls to change server > > in a week we have 8 servers 16 vote admins 32 vote supervisers and 64 > different outcomes of the previous vote > > we can get rich by renting out all that vote infra we soon will have ;) The only reason to have our own vote server in the first place was that the one run by its author [2] did not implement proportional representation at the time. That has now changed, so I propose we simply switch to it. [1] http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-October/316367.html [2] https://civs1.civs.us/ -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
On Sun, Nov 12, 2023 at 06:43:28PM +0100, J. Dekker wrote: > On Sun, Nov 12, 2023, at 18:31, Michael Niedermayer wrote: > > On Sun, Nov 12, 2023 at 11:03:21AM -0300, James Almer wrote: > >> On 11/12/2023 10:59 AM, Thilo Borgmann via ffmpeg-devel wrote: > >> > I will also start the repeat vote now and everybody can hold their > >> > horses before going to flamewar. Depending on JB's explanations, he > >> > might still prove that the old vote is valid and this repeat vote > >> > becomes void. > >> > >> Or you could have waited for his answer before doing the vote, don't you > >> think? Now people got a new vote email that may or may not be valid at all. > > > > I hope this new vote will result in the same winner as the last > > because otherwise we will have more questions and accusations > > Multiple people (including myself) have already posted their voting URLs > publicly > so this 'vote' outcome will be extremely questionable at best. i saw it. I guess its your right to protest that way, its your ballot its a bit unfortunate. i have not really finished investigating what exactly happened in the previous vote, but more information is still trickling in. There where mistakes made in the previous vote though i doubt they affected the outcome, but i do not know I think anton, thilo and jb should have paused the votes and waited until we fully understand the previous votes issues. now it becomes only more messy previous vote, repeat vote, some agree some disagree thats the right path next votes following on top of ? some calls to changes to vote admin, some calls to change vote superviser some calls to change server in a week we have 8 servers 16 vote admins 32 vote supervisers and 64 different outcomes of the previous vote we can get rich by renting out all that vote infra we soon will have ;) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In fact, the RIAA has been known to suggest that students drop out of college or go to community college in order to be able to afford settlements. -- The RIAA signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
On Sun, Nov 12, 2023, at 18:31, Michael Niedermayer wrote: > On Sun, Nov 12, 2023 at 11:03:21AM -0300, James Almer wrote: >> On 11/12/2023 10:59 AM, Thilo Borgmann via ffmpeg-devel wrote: >> > I will also start the repeat vote now and everybody can hold their >> > horses before going to flamewar. Depending on JB's explanations, he >> > might still prove that the old vote is valid and this repeat vote >> > becomes void. >> >> Or you could have waited for his answer before doing the vote, don't you >> think? Now people got a new vote email that may or may not be valid at all. > > I hope this new vote will result in the same winner as the last > because otherwise we will have more questions and accusations Multiple people (including myself) have already posted their voting URLs publicly so this 'vote' outcome will be extremely questionable at best. -- jd ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
On Sun, Nov 12, 2023 at 11:03:21AM -0300, James Almer wrote: > On 11/12/2023 10:59 AM, Thilo Borgmann via ffmpeg-devel wrote: > > I will also start the repeat vote now and everybody can hold their > > horses before going to flamewar. Depending on JB's explanations, he > > might still prove that the old vote is valid and this repeat vote > > becomes void. > > Or you could have waited for his answer before doing the vote, don't you > think? Now people got a new vote email that may or may not be valid at all. I hope this new vote will result in the same winner as the last because otherwise we will have more questions and accusations thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
On 11/12/2023 10:59 AM, Thilo Borgmann via ffmpeg-devel wrote: I will also start the repeat vote now and everybody can hold their horses before going to flamewar. Depending on JB's explanations, he might still prove that the old vote is valid and this repeat vote becomes void. Or you could have waited for his answer before doing the vote, don't you think? Now people got a new vote email that may or may not be valid at all. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
On Sun, Nov 12, 2023 at 2:59 PM Thilo Borgmann via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote: > Hi, > > for privacy reasons I must use JB's quote as given in the archives and > need to drag this reply up one level. If the addresses in the > redacted part need to be referred to, they shall be referred to as > AddressA and AddressB. > > I will address more replies once time allows, JB's reply is actually the > one mail that addresses the cause of this whole mess so I reply to it now > (asap). > > I will also start the repeat vote now and everybody can hold their horses > before going to flamewar. Depending on JB's explanations, he might still > prove that the old vote is valid and this repeat vote becomes void. Anyway, > if he cannot, this needs to follow the given timeframe. > > On we go: > > > Am 11.11.23 um 10:54 schrieb Jean-Baptiste Kempf: > > On Sat, 11 Nov 2023, at 08:22, Thilo Borgmann via ffmpeg-devel wrote: > >> Neither does this list of 51 people [1] correlate to the 54 authorized > voters > >> (distinct email addresses) the CIVS system actually counted, see [3]. > > > > And instead of you ASKING for that, you launch another vote? That's your > solution? > > Very well, then let me ask you to share, even privately if you have > privacy concerns, the following data that might help to invalidate my > claims and probably shortcut the whole when what and how questions in the > other half of the mail: > - The file(s) you used for the first and second batch. I'd assume you did > the editing you mention below in the same file, so it's of course > reasonable if you therefore could only share the one file used for the > second batch after editing. > - The mail the poll supervisor gets with the subject like "CIVS poll > created: " so that I can look at the control panel. The mail > says you should keep it private so nobody can interrupt with the poll in > progress. The vote is over, results known and a lockfile set so nothing can > happen anymore to the vote. > > > > Just as as remark, YOU are running the voting system, and have access to > infra, so YOU can check it. > > > > > > The answer is simple, Linjie Fu has had several emails in use, (one with > and one without justin) and one of them is bouncing. I remembered that > after sending the first batch, so I added it back, knowing that he/she > could only vote once. > > Same reason for Ruiling Song who has both an Intel and a gmail email. > > Finally, in the emails, there was REDACTED FOR GDPR/PRIVACY. It was > probably the reason. > > This is not completely clear to me so let me ask for clarification here as > well. > > The logfile (attached) says: > The first batch sent out were 53 mails (from 10:11:19 to 10:12:20) > The second batch sent out were 53 mails (from 10:16:20 to 10:16:48) > One single mail was sent (at 12:55:40) > In the end, the counter is at 54. > In the end, you named 51 distinct people. > > So the first batch must have been 53 distinct mail addresses, raising the > counter from 0 to 53. > The second batch must also have contained 53 distinct mail addresses > because 53 mails have been sent. > After the second batch, the counter must have been at 53 or 54 already, > depending on wether or not the one single mail that was sent afterwards was > already in one of the batches or yet another distinct mail address > (counter++). > > What I understand from your simple answer, is you changed two mail > addresses in between batch one and two (Linjie & Ruiling). > That would have risen the counter from 53 to 55 after sending the second > batch because the two corrected addresses are distinct and counted. > Depending on wether or not the one single mail that was sent afterwards > was already in one of the batches or yet another distinct mail address > (counter++), > the counter would have to be 55 or 56. > > Can you clarify what mail addresses you changed from what into what > between batch one and batch two? > Can you clarify if the single mail that was sent afterwards was already in > one of the batches or yet another distinct mail address? > > Thank you for officially killing project. > > > > > And that's why you see 3 more emails than names. And that cannot change > anything to the vote. > > > > jb > > > > -Thilo___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
Hi, for privacy reasons I must use JB's quote as given in the archives and need to drag this reply up one level. If the addresses in the redacted part need to be referred to, they shall be referred to as AddressA and AddressB. I will address more replies once time allows, JB's reply is actually the one mail that addresses the cause of this whole mess so I reply to it now (asap). I will also start the repeat vote now and everybody can hold their horses before going to flamewar. Depending on JB's explanations, he might still prove that the old vote is valid and this repeat vote becomes void. Anyway, if he cannot, this needs to follow the given timeframe. On we go: Am 11.11.23 um 10:54 schrieb Jean-Baptiste Kempf: On Sat, 11 Nov 2023, at 08:22, Thilo Borgmann via ffmpeg-devel wrote: Neither does this list of 51 people [1] correlate to the 54 authorized voters (distinct email addresses) the CIVS system actually counted, see [3]. And instead of you ASKING for that, you launch another vote? That's your solution? Very well, then let me ask you to share, even privately if you have privacy concerns, the following data that might help to invalidate my claims and probably shortcut the whole when what and how questions in the other half of the mail: - The file(s) you used for the first and second batch. I'd assume you did the editing you mention below in the same file, so it's of course reasonable if you therefore could only share the one file used for the second batch after editing. - The mail the poll supervisor gets with the subject like "CIVS poll created: " so that I can look at the control panel. The mail says you should keep it private so nobody can interrupt with the poll in progress. The vote is over, results known and a lockfile set so nothing can happen anymore to the vote. Just as as remark, YOU are running the voting system, and have access to infra, so YOU can check it. The answer is simple, Linjie Fu has had several emails in use, (one with and one without justin) and one of them is bouncing. I remembered that after sending the first batch, so I added it back, knowing that he/she could only vote once. Same reason for Ruiling Song who has both an Intel and a gmail email. Finally, in the emails, there was REDACTED FOR GDPR/PRIVACY. It was probably the reason. This is not completely clear to me so let me ask for clarification here as well. The logfile (attached) says: The first batch sent out were 53 mails (from 10:11:19 to 10:12:20) The second batch sent out were 53 mails (from 10:16:20 to 10:16:48) One single mail was sent (at 12:55:40) In the end, the counter is at 54. In the end, you named 51 distinct people. So the first batch must have been 53 distinct mail addresses, raising the counter from 0 to 53. The second batch must also have contained 53 distinct mail addresses because 53 mails have been sent. After the second batch, the counter must have been at 53 or 54 already, depending on wether or not the one single mail that was sent afterwards was already in one of the batches or yet another distinct mail address (counter++). What I understand from your simple answer, is you changed two mail addresses in between batch one and two (Linjie & Ruiling). That would have risen the counter from 53 to 55 after sending the second batch because the two corrected addresses are distinct and counted. Depending on wether or not the one single mail that was sent afterwards was already in one of the batches or yet another distinct mail address (counter++), the counter would have to be 55 or 56. Can you clarify what mail addresses you changed from what into what between batch one and batch two? Can you clarify if the single mail that was sent afterwards was already in one of the batches or yet another distinct mail address? And that's why you see 3 more emails than names. And that cannot change anything to the vote. jb -ThiloMon Oct 30 10:11:19 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:20 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:20 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:21 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:41 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:41 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:42 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:44 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:45 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:45 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:46 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:47 2023 127.0.0.1 Sending mail to a voter for poll
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
On Sat, Nov 11, 2023 at 2:22 AM Thilo Borgmann via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote: > Hi, > > in [1] JB listed his list of authorized voters for the "GA voters list > updates" > vote. > > This list does not correlate with the list Josh provided in [2]. > Neither does this list of 51 people [1] correlate to the 54 authorized > voters > (distinct email addresses) the CIVS system actually counted, see [3]. > > This can mean only one of two things, either some people on the list in > [1] did > receive more than one ballot, or JB failed to list all the authorized > voters and > ballots have been given to unknown people. Both possibilities are > unacceptable > flaws for a democratic vote. > > As the admin responsible of the votes it is my duty to have supervision of > all > polls and thus it is my duty to declare this vote null and void for the > flaws > given above. > > This vote will be repeated from Sun 12th of November to Sunday 19th of > November > so we don't have to move the following votes yet another time. > It will be using the list given by Josh [2] as it seems to be the closest > to the > truth we can get. The old extra members of the GA have become void > according to [4] > and will not be included. > > Furthermore, I patched the voting system to log all authorized voters in > the > future to prevent this situation in the future. > > The authorized voters for the repeated vote [2] reads as follows: > > [email list snipped] > > -Thilo > > [1] > https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-November/316594.html > [2] https://www.irccloud.com/pastebin/KNrvxILA/Votes_2020.txt > [3] https://vote.ffmpeg.org/cgi-bin/civs/results.pl?id=E_029f7195fed7aadf > [4] https://ffmpeg.org/community.html#General-Assembly-1 > ___ > This is why we cannot have nice things. -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
On Sat, Nov 11, 2023 at 05:58:43PM +0100, Nicolas George wrote: > Michael Niedermayer (12023-11-11): > > Also iam not sure resending mails to different addressed when they bounce > > is safe > > Lets just consider i receive a mail at niedermayer.cc, i could construct a > > bounce and > > send it back while still voting with the token in it. If i now get a mail > > at gmx.at > > i could vote twice. > > I am confused: you would get the same token in the second mail, you > would not be able to use it twice. yes, i got 2 emails with the same url with teh same token in it so i can only vote once with that (each token can only vote once) id have to check the CIVS source on how this is achieved. i guess its either storing the emails or hashes of them. or the tokens are computed from the emails so the same email results in the same token thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "Nothing to hide" only works if the folks in power share the values of you and everyone you know entirely and always will -- Tom Scott signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
On Sat, 11 Nov 2023, at 17:58, Nicolas George wrote: > Michael Niedermayer (12023-11-11): >> Lets just consider i receive a mail at niedermayer.cc, i could construct a >> bounce and >> send it back while still voting with the token in it. If i now get a mail at >> gmx.at >> i could vote twice. > > I am confused: you would get the same token in the second mail, you > would not be able to use it twice. Nicolas is very correct here: in some of the test voting, some people got the email twice, and could vote only once. TBH, all e-voting systems work like that AFAIK -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
Michael Niedermayer (12023-11-11): > Also iam not sure resending mails to different addressed when they bounce is > safe > Lets just consider i receive a mail at niedermayer.cc, i could construct a > bounce and > send it back while still voting with the token in it. If i now get a mail at > gmx.at > i could vote twice. I am confused: you would get the same token in the second mail, you would not be able to use it twice. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
Hi jb and everyone else On Sat, Nov 11, 2023 at 10:54:20AM +0100, Jean-Baptiste Kempf wrote: > On Sat, 11 Nov 2023, at 08:22, Thilo Borgmann via ffmpeg-devel wrote: > > Neither does this list of 51 people [1] correlate to the 54 authorized > > voters > > (distinct email addresses) the CIVS system actually counted, see [3]. > > And instead of you ASKING for that, you launch another vote? That's your > solution? I cannot speak for thilo, but i did what you suggest here and asked about multiple other inconsistencies in the vote. The replies i got where minimal, slow and at least one was not friendly at all Also IMHO if inconsistencies occure in a vote they should be made public with no one having to ask explicitly. Being reluctant to share information about problems that occured in a vote is not good practice in a open source project IMHO and also it leads to more distrust and more drama (like what started this thread) > > Just as as remark, YOU are running the voting system, and have access to > infra, so YOU can check it. thilo did share the log with me a few days ago, there is very little information in it. So little i can just provide it here with no privacy fears ill provide a summary first: (as its easier to read i think) 4 mails where sent out Mon Oct 30 10:11:20 +-1sec then 20 seconds pass then 47 mails are sent out between 10:11:41 and 10:12:20 with 0-2 seconds between the mails then 11 seconds pass then 2 mails are sent out at 10:12:31 at 10:13:42 2023 the first vote comes in then about 3 minutes pass between 10:16:20 and 10:16:48 53 mails are sent with 0-3 seconds between over 2 hours later at 12:55:40 another mail is sent overall 54 mails sent where distinct but we do not know the addresses, I do believe CIVS will not resend mails to the same address unless asked for and the same address will not be able to vote twice or be counted twice. But anyone who is in there with 2 different addresses could vote twice Now if CIVS can ensure the same address cannot vote twice it must be possible to extract the email addresses, at least before the end of the vote, But i do not know how. CIVS seems to have it as one of its goals to keep the addresses out of the logs it seems thats a mis-feature to me Also iam not sure resending mails to different addressed when they bounce is safe Lets just consider i receive a mail at niedermayer.cc, i could construct a bounce and send it back while still voting with the token in it. If i now get a mail at gmx.at i could vote twice. IMHO it should be ensured that the addresses are working before the vote and not updating them during the vote Mon Oct 30 10:11:19 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:20 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:20 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:21 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:41 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:41 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:42 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:44 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:45 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:45 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:46 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:47 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:47 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:48 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:49 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:51 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:52 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:52 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:53 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:56 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:57 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:57 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:58 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:58 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:12:00 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:12:01 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:12:02 2023 127.0.0.1 Sending mail to a voter
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
On 11/11/2023 4:22 AM, Thilo Borgmann via ffmpeg-devel wrote: Hi, in [1] JB listed his list of authorized voters for the "GA voters list updates" vote. This list does not correlate with the list Josh provided in [2]. Neither does this list of 51 people [1] correlate to the 54 authorized voters (distinct email addresses) the CIVS system actually counted, see [3]. This can mean only one of two things, either some people on the list in [1] did receive more than one ballot, or JB failed to list all the authorized voters and ballots have been given to unknown people. Both possibilities are unacceptable flaws for a democratic vote. Neither of these happened. It was already explained what happened. As the admin responsible of the votes it is my duty to have supervision of all polls and thus it is my duty to declare this vote null and void for the flaws given above. No, this is completely unacceptable. This vote will be repeated from Sun 12th of November to Sunday 19th of November so we don't have to move the following votes yet another time. As others pointer out, not only would such a vote not give a different result if run with the list you shared in this email, as it's the same people + duplicate addresses, but a repeated vote knowing the result beforehand might affect people's choice, or outright have people not bother voting at all. So again, this is not ok at all and it damages the credibility of the entire system. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
Le lauantaina 11. marraskuuta 2023, 13.15.37 EET Nicolas George a écrit : > Rémi Denis-Courmont (12023-11-11): > > 1) As far as was communicated, the total of alleged discrepancies in the > > voter list could not affect the result. That makes the vote valid in my > > book, and also in the legal or predecential standards in democracies: if > > elections were overturned for every inconsequential irregularities, they > > would practically never be valid. > > Except in democracies, it is not the same electoral commission that will > both make the mistakes that can be suspected to be fraud and declare > these mistakes are unimportant. This is veering very off-topic and I think we should leave personal perceptions of country politics out of ffmpeg-devel. With that said, I have been both a voting booth attendant and a vote counter in official country election. There are plenty of honest and inconsequential mistakes made, mostly by the voters, occasionally by the volunteers like myself. As for the willful violations, such as ballot stuffing or breaking in, they also do tend to take place at voting stations. Point being, the mistakes are not typically made by the commission. > I must say, my trust in some of the people running this thing is sinking > rapidly. I sympathetise with the feeling but we can't have it both ways: a remote system with automatically determined voting eligibility, and a transparent trustworthy verifiable system. The alternative is that people have to go to FOSDEM or VDD to vote in person. I guess that Michael, you and a number of other voters would not want that... -- Rémi Denis-Courmont http://www.remlab.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
Rémi Denis-Courmont (12023-11-11): > 1) As far as was communicated, the total of alleged discrepancies in the > voter > list could not affect the result. That makes the vote valid in my book, and > also in the legal or predecential standards in democracies: if elections were > overturned for every inconsequential irregularities, they would practically > never be valid. Except in democracies, it is not the same electoral commission that will both make the mistakes that can be suspected to be fraud and declare these mistakes are unimportant. I must say, my trust in some of the people running this thing is sinking rapidly. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
Le lauantaina 11. marraskuuta 2023, 9.22.19 EET Thilo Borgmann via ffmpeg-devel a écrit : > As the admin responsible of the votes it is my duty to have supervision of > all polls and thus it is my duty to declare this vote null and void for the > flaws given above. As noted several times by several people: 1) As far as was communicated, the total of alleged discrepancies in the voter list could not affect the result. That makes the vote valid in my book, and also in the legal or predecential standards in democracies: if elections were overturned for every inconsequential irregularities, they would practically never be valid. 2) As Lynne already pointed out, at this point, after results were published and voters expressed their frustration with your attempt to recall it, and forcing a vote amounts to nothing but manipulation - even if this is perhaps not your intention. If people would vote the same way they did, the result would be the same (as per the first point), regardless fo extra voters. So redoing the vote only makes sense if you expect to achieve different results by changing people's opinion or getting them to abstain. 3) As Anton already pointed out, you do not seem to have standing to declare a vote null in the first place. You were trusted to operate the voting system, not to determine the validaty of the vote. 4) As a consequence (of the previous point), this is an attempt to abuse your privileges as an adminstrator. This will be reported to the CC. 5) You are spreading more unnecessary discredit on the community and its processes, and just creatied a new convenient pretext for people to claim that the GA, CC and TC have no authority. (Previously the pretext was that the later two had expired.) This makes it an attack against the community as a whole. 6) That is yet another indirect attack against new developers (including but not limited to myself). I do very much take offense. I declare your mail null and void for all purposes other than the CC investigating your potential violations of applicable rules. It should go without spelling it out but such community-hostile attitude seems very ill-advised to me for somebody who is running for CC election or reelection. -- Rémi Denis-Courmont http://www.remlab.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
On Sat, 11 Nov 2023, at 08:22, Thilo Borgmann via ffmpeg-devel wrote > The authorized voters for the repeated vote [2] reads as follows: > > mich...@niedermayer.cc > one...@gmail.com > jamr...@gmail.com > andreas.rheinha...@gmail.com > s...@jkqxz.net > c...@passwd.hu > ceffm...@gmail.com > barryjz...@tencent.com > liuq...@kuaishou.com > lance.lmw...@gmail.com > martin.vign...@gmail.com > ffm...@gyani.pro > a...@tmm1.net > mar...@martin.st > di...@biurrun.de > lizhong1...@gmail.com > d...@lynne.ee > nfx...@googlemail.com > an...@khirnov.net > atomnu...@gmail.com > t...@rothenpieler.org > u...@pkh.me > geo...@nsup.org > yejun@intel.com > linjie...@intel.com > kaustubh.ra...@imgtec.com > stebb...@jetheaddev.com > phil...@overt.org > andriy.gel...@gmail.com > vittorio.giov...@gmail.com > jerome.borsb...@carpalis.nl > derek.buitenh...@gmail.com > pr...@xvid.org > j...@itanimul.li > kjeya...@akamai.com > dalecur...@chromium.org > jee...@gmail.com > t.r...@noa-archive.com > vdi...@akamai.com > zhiliz...@tencent.com > matthieu.bou...@gmail.com > yinshiyou...@loongson.cn > z...@zanevaniperen.com > ruiling.s...@intel.com > kjeya...@akamai.com > hwr...@126.com > modma...@google.com > c...@gmx.com > fooba...@gmail.com > baptiste.coudur...@gmail.com You have been told, now, several times, that a list of email is a collection of Private Information, according to a GDPR and that you are a process of this PI, and therefore liable to the law. However, neither YOU nor the legal owner FFmpeg.org explain how you will retain this information, process it further, OR, as the most important part, remove it from this mailing lists archive, when requested or when the time is over. This is illegal. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
Nov 11, 2023, 08:58 by an...@khirnov.net: > Also as I said before, option A won its contests against options B/C/D > by 17/7, 23/1, and 17/7, respectively. You would thus need to change 10 > votes to have any chance of a different result. As the number of > disputed voters is nowhere near 10, there is no point in repeating > anything. > The voting wouldn't be genuine either, as the results have been revealed and everyone knows how much each option voted, which would allow for manipulation. Given how much time these discussions took out of coding, and making a release, and given that the list has just been refreshed, I think we should carry on with it, particularly as it will change every 6 months anyway, giving everyone a chance to participate. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
> -Original Message- > From: ffmpeg-devel On Behalf Of Anton > Khirnov > Sent: 2023年11月11日 15:58 > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates > > Quoting Thilo Borgmann via ffmpeg-devel (2023-11-11 08:22:19) > > Hi, > > > > in [1] JB listed his list of authorized voters for the "GA voters list > > updates" > > vote. > > > > This list does not correlate with the list Josh provided in [2]. > > The word 'correlate' does not mean what you seem to think it means. The > list does correlate. > > > Neither does this list of 51 people [1] correlate to the 54 authorized > > voters > > (distinct email addresses) the CIVS system actually counted, see [3]. > > > > This can mean only one of two things, either some people on the list in [1] > > did > > receive more than one ballot, or JB failed to list all the authorized > > voters and > > ballots have been given to unknown people. Both possibilities are > > unacceptable > > flaws for a democratic vote. > > > > As the admin responsible of the votes it is my duty to have supervision of > > all > > polls and thus it is my duty to declare this vote null and void for the > > flaws > > given above. > > I am not aware of anyone having given you the right to do this. > > > mich...@niedermayer.cc > > one...@gmail.com > > jamr...@gmail.com > > andreas.rheinha...@gmail.com > > s...@jkqxz.net > > c...@passwd.hu > > ceffm...@gmail.com > > barryjz...@tencent.com > > liuq...@kuaishou.com > > lance.lmw...@gmail.com > > martin.vign...@gmail.com > > ffm...@gyani.pro > > a...@tmm1.net > > mar...@martin.st > > di...@biurrun.de > > lizhong1...@gmail.com > > d...@lynne.ee > > nfx...@googlemail.com > > an...@khirnov.net > > atomnu...@gmail.com > > t...@rothenpieler.org > > u...@pkh.me > > geo...@nsup.org > > yejun@intel.com > > linjie...@intel.com > > kaustubh.ra...@imgtec.com > > stebb...@jetheaddev.com > > phil...@overt.org > > andriy.gel...@gmail.com > > vittorio.giov...@gmail.com > > jerome.borsb...@carpalis.nl > > derek.buitenh...@gmail.com > > pr...@xvid.org > > j...@itanimul.li > > kjeya...@akamai.com > > dalecur...@chromium.org > > jee...@gmail.com > > t.r...@noa-archive.com > > vdi...@akamai.com > > zhiliz...@tencent.com > > matthieu.bou...@gmail.com > > yinshiyou...@loongson.cn > > z...@zanevaniperen.com > > ruiling.s...@intel.com > > kjeya...@akamai.com > > hwr...@126.com > > modma...@google.com > > c...@gmx.com > > fooba...@gmail.com > > baptiste.coudur...@gmail.com > > This list contains at least two duplicates, easily found by inspection. > This gives me zero confidence that any hypothetical new vote would be > any more reliable than the old one. > > Also as I said before, option A won its contests against options B/C/D > by 17/7, 23/1, and 17/7, respectively. You would thus need to change 10 > votes to have any chance of a different result. As the number of > disputed voters is nowhere near 10, there is no point in repeating > anything. I abstain if there will another vote. I can't believe how much time have been taken on this than do some real work, like coding and patch review, and improve the situation of patch review. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
Quoting Thilo Borgmann via ffmpeg-devel (2023-11-11 08:22:19) > Hi, > > in [1] JB listed his list of authorized voters for the "GA voters list > updates" > vote. > > This list does not correlate with the list Josh provided in [2]. The word 'correlate' does not mean what you seem to think it means. The list does correlate. > Neither does this list of 51 people [1] correlate to the 54 authorized voters > (distinct email addresses) the CIVS system actually counted, see [3]. > > This can mean only one of two things, either some people on the list in [1] > did > receive more than one ballot, or JB failed to list all the authorized voters > and > ballots have been given to unknown people. Both possibilities are unacceptable > flaws for a democratic vote. > > As the admin responsible of the votes it is my duty to have supervision of all > polls and thus it is my duty to declare this vote null and void for the flaws > given above. I am not aware of anyone having given you the right to do this. > mich...@niedermayer.cc > one...@gmail.com > jamr...@gmail.com > andreas.rheinha...@gmail.com > s...@jkqxz.net > c...@passwd.hu > ceffm...@gmail.com > barryjz...@tencent.com > liuq...@kuaishou.com > lance.lmw...@gmail.com > martin.vign...@gmail.com > ffm...@gyani.pro > a...@tmm1.net > mar...@martin.st > di...@biurrun.de > lizhong1...@gmail.com > d...@lynne.ee > nfx...@googlemail.com > an...@khirnov.net > atomnu...@gmail.com > t...@rothenpieler.org > u...@pkh.me > geo...@nsup.org > yejun@intel.com > linjie...@intel.com > kaustubh.ra...@imgtec.com > stebb...@jetheaddev.com > phil...@overt.org > andriy.gel...@gmail.com > vittorio.giov...@gmail.com > jerome.borsb...@carpalis.nl > derek.buitenh...@gmail.com > pr...@xvid.org > j...@itanimul.li > kjeya...@akamai.com > dalecur...@chromium.org > jee...@gmail.com > t.r...@noa-archive.com > vdi...@akamai.com > zhiliz...@tencent.com > matthieu.bou...@gmail.com > yinshiyou...@loongson.cn > z...@zanevaniperen.com > ruiling.s...@intel.com > kjeya...@akamai.com > hwr...@126.com > modma...@google.com > c...@gmx.com > fooba...@gmail.com > baptiste.coudur...@gmail.com This list contains at least two duplicates, easily found by inspection. This gives me zero confidence that any hypothetical new vote would be any more reliable than the old one. Also as I said before, option A won its contests against options B/C/D by 17/7, 23/1, and 17/7, respectively. You would thus need to change 10 votes to have any chance of a different result. As the number of disputed voters is nowhere near 10, there is no point in repeating anything. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
