On 3/16/24 22:25, Pete Resnick wrote:
So, as I said earlier, many things have changed, and in this case I disagree that the 2-week moratorium on posting is needed anymore. As Keith pointed, there were two reasons we set up the moratorium in the first place: (1) The secretariat had to hand-process I-Ds back in the day and was swamped before the meeting; and (2) In order to be prepared for the meeting, you wanted to have people to read the same version of the document so that everyone was on the same page. Only later, as a side effect, did we get reason (3): People act well in the face of deadlines, and this one was conveniently imposed due to other considerations.
Well we had deadlines before we had the 2-week moratorium - it's just that the deadline was effectively the night before the meeting. And deadlines can help drive work, but I would argue that a 2-week deadline works better than a 1-day deadline at least in part because lots of people are trying to get their lives in order in order to travel to those meetings, and that distracts from actually getting drafts completed in time to be reviewed before the meetings.
I don't think that diffs, in general, make up for late changes. If the changes are only minor wording changes, maybe. But it's also possible to do significant restructuring of a document just before a meeting, which is poor timing IMO. That's not an argument that the 2-week rule is optimum, but at least it's a rule that's simple and easily understood.
IMO the 2-week (or whatever) rule should apply to EVERY way of updating a document, including git updates. (maybe not pull requests, since those are just suggestions, after all.)
So I'd argue to keep the 2-week rule because I think it's about the minimum amount of time that it's reasonable to give people to sync / catch up, but the 2-week rule should apply to all updates. I don't know that the tools need to enforce this rule, though. There's such a thing as too much tooling. Maybe just create a branch named after the meeting date, and let it be understood that it's that branch that's being reviewed and discussed at the meeting. (others with more familiarity with git/github than I have might have better ideas.)
Keith
