I completely agree with you, Mike. Lack of transparency in the decision making process is a problem and pre-dates the use of Github. I am not sure whether our use of Github improved it or made it worse. Chairs need to be aware of those problems and alert. I know that this is difficult because it puts a lot on the shoulders of the WG chairs, and often they are conflicted when half of the active working group members work for the same company. This discussion is a bit tricky because we all have specific problems in mind but nobody wants to mention any specific cases. Ciao Hannes -----Original Message----- From: ietf <ietf-bounces@xxxxxxxx> On Behalf Of Michael Thomas Sent: Thursday, January 7, 2021 6:03 PM To: ietf@xxxxxxxx Subject: Re: Old directions in social media. On 1/7/21 8:43 AM, Hannes Tschofenig wrote: > Hi Joel, > > Everyone wants to have more effective reviews. We have an agreement there. > > Where it gets tricky is how to accomplish this (ignoring what "effective" precisely means). > > The discussion moved into "I want to use my tools and not yours". There is no middle ground. You want to have everyone use email so you can scan through discussions more easily. Others, who have been working on implementations are familiar with Git, and they seem to feel that they are most efficient using those tools. > As I said elsewhere, the problem as I see it with the way that most working groups I have been a part of is that the actual editing of the document is not very transparent and often just the author's take on consensus which can obviously be self-serving if they want to be. Having an audit trail of when and why changes were made would be a definite move in the right direction. It would also give the chairs an easy way to cross check changes where consensus was dubious or not achieved. Pull requests seem a little baroque, but they are baroque in git too, imo. But there is no good way to formally ask that a specific change be made in a specific part of the document. That tends to get lost in the back and forth of mailing list traffic. The problem with a pull request per se is that if it's not a nit it needs to be determined if it has consensus. That's not a problem with the normal use of git, but is problematic with consensus driven IETF: authors shouldn't be the ones arbitrarily calling consensus, though that is often the case by default. Mike IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
