Re: Question about pre-meeting document posting deadlines for the IESG and the community

[Keith Moore <[e-mail]>]

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