Re: Old directions in social media.

["Joel M. Halpern" <[e-mail]>]

Maybe I am missing something.  You refer to transparency of changes. 
For any document I care about, I look at the diffs between versions as 
well as at the resulting whole document.

If authors want to use git for storing documents and tracking what they 
do, that is likely beneficial to the working group.  But that has little 
or nothing to do with discussing issues on the WG email list.

Yours,
Joel

On 1/7/2021 12:03 PM, Michael Thomas wrote:
> 
> 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
>