On Mon, Jan 15, 2024 at 2:18 AM Christofer Dutz <christofer.d...@c-ware.de> wrote: > > Hi Christopher, > > I do understand that some of the things Apache requires from its projects may > seem obsolete and outdated.
I hope I didn't give the impression that that's what I think. I know it's a common sentiment, but not one I hold. [snip] > So, the thing is … the “binding” is important. One of the main pillars of > Apache is the legal shield. This protects our contributors from prosecution. I understand and agree. But the important bit (and the requirement) is to *be* binding, not to use the word "binding". Merely using the word has no effect other than to give the impression that whoever used it understands what it means, which might not be the case. My point was just that the release manager (and anybody else who wishes to audit the tally) still has to check that votes are, in fact, binding, regardless of what they say. So, *using* the word "binding" doesn't actually seem to save anybody any work... you still gotta check, and that's what we do. [snip] > I didn’t start doing these very thorough checks every month because I wanted > to invest so much time. Initially I started reading the board reports, maybe > asking a question or two and then signing them off … however did I learn > quite quickly that these board reports don’t always reflect reality. [snip] > So please forgive me, that I don’t blindly trust every project that they are > doing everything right. I think I would be doing a bad job if I was doing > that. That’s also why I started writing hopefully friendly “personal > feedback” emails. > > By simply adding a “binding” in the result email you at least tell me that > you have paid attention to the difference of binding and non-binding votes > (believe me … there are projects that don’t understand the difference) and in > that case, I usually don’t validate the correctness if I don’t have a reason > to doubt it. You are just making things easier for people doing unpleasant > jobs like investing 2-3 full working days (mostly on the weekend and after > work) each month with nothing else than having 2-3 coffee and reviewing the > projects activity. > I appreciate that you're doing that extra quality control and oversight work. I can imagine it's a lot. I just don't see how having the word "binding" anywhere would have helped you reduce your audit workload. This is because I would be wary about "blindly trusting" that projects who use the word "binding" are actually using it correctly. A project can still add the word "binding" with a misunderstanding of what that word means, or worse, they could be lazy and just add the word because they know you're looking for it, without actually doing any due diligence to check that the votes were, in fact, binding ones. In order to properly audit that votes are being tallied correctly, you still have to dig just as deep to verify. If anything, I think it'd be better to say something like "x +1 votes from PMC members" rather than "x binding +1 votes". The former doesn't use the word "binding", but still demonstrates what it means for the votes to *be* binding, better than merely using the word. In any case, I hope I've at least reassured you that our project does, in fact, know the difference, and are tallying our votes correctly. In future, we can try to include wording in our RESULT emails that makes it more clear that the votes we've tallied represent binding ones. > > > Thanks, and sorry for the many words in this email ;-) > No worries. I understand the feeling. I write long emails too. I composed this response in 5 minutes, and spent 3 hours trying to edit it down. I hope you were more efficient with your time! LOL > > > > > Chris > > > > > > Von: Christopher <ctubb...@apache.org> > Datum: Montag, 15. Januar 2024 um 00:21 > An: accumulo-dev <dev@accumulo.apache.org> > Cc: cd...@apache.org <cd...@apache.org> > Betreff: Re: Personal feedback on your last release vote-thread > > Hi Christofer, > > > > I've seen other projects do this and I disagree that it's useful for us to do > that on each vote. > > > > First, we are a relatively small community of active committers and typically > already aware of who among us is in the PMC and who isn't. > > > > Second, aside from a few emeritus PMC members, all our committers are also > PMC members. And we have a relatively low barrier to entry. So we only have a > handful of active contributors who aren't PMC members at any given time, and > we'd notice if they voted, or if somebody we didn't recognize tried to vote. > > > > Third, on the rare occasion when a non-committer votes, they usually specify > non-binding. > > > > Fourth, and most importantly, specifying that a vote is binding doesn't make > it binding. What makes it binding is if the voter is a PMC member. If the > release manager who tallies the vote isn't already aware of who is a PMC > member or not, it would be their responsibility to check, regardless of what > the voter said about their own vote, and the tally is subject to review by > all for correction. So, specifying it doesn't actually help at all. It just > adds noise. I actually think that specifying it is counter productive, > because the release manager could start relying on what the user said instead > of doing their due diligence to verify when they tally. > > > > Speaking frankly, I don't personally find it useful, and I'm most often the > one lately who steps up to be a release manager for our votes. I verify every > time who is on the PMC list, regardless of what people say in their vote, as > I consider it the responsibility of whoever tallies the vote to get an > accurate count, and I would do the same to verify the tally if somebody else > were to do it. I think this practice of declaring a vote binding is one of > those strange customs that has worked its way into some projects because > somebody did it once and others copied it without questioning it's value. But > I have questioned its value and find it to be without any. > > > > As for mentioning it in the RESULT email, if there are both kinds of votes, > we do mention the non-binding ones separately. In our last RESULT email, > however, I merely said that it "passes with 6 +1s". Since we are aware that > only binding votes can cause a vote to pass, it is clearly implied that they > were binding. Ultimately, this comes down to trust. If you trust that we > tallied the vote correctly, then mentioning they were binding votes is merely > redundant. However, if you don't trust that we did it correctly, or just want > to double check, then you should not merely accept what we said and should > check each vote regardless of what we said, just as you did. In either case, > explicitly specifying that they were binding doesn't actually help, I think > > > > Regardless, thank you for double checking our tally and for providing this > feedback. If it helps, we can try to be more clear in the RESULT emails with > some redundancy, but I think it's strange to trust a count more just because > of the presence of redundant phrasing. If I were to audit a vote, I'd check > the count, regardless of how it was phrased. I also don't think it's useful > at all to ask all voters to specify it in their individual votes, for the > reasons stated above, especially that it's a potentially harmful custom if > the release manager relies on it. > > > > Kind regards, > > Christopher > > > > > > On Sun, Jan 14, 2024, 10:14 Christofer Dutz <cd...@apache.org> wrote: > > Hi all, > > while reviewing the project's activity as part of me preparing for the > upcoming board meeting, i noticed that in the last vote thread, there were > only simple +1 votes and no mentions of them being binding votes or not. Even > if this is quite common throughout project, it would be good, if in the > result email they would explicitly be mentioned as binding votes, if they > were counted as such. > > I currently had to check each name with the PMC list in order to check that > they were all actually binding votes. > > Chris > > PS: If you reply to this email, please make sure I'm in CC, as I'm not > subscribed to this list.
