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
