But in my experience: humans have errors (Ex: Notetaker writes down 1/2/2021 instead of 2/1/2021). Having a formal "last call" for record-changes is useful for catching these mistakes.
In my entire management experience over multiple years, the "not well understood" part has never happened. If I were to guess, it could be due to the goal setting exercise at the beginning of a project. I, as a lead, sit down with the team and clearly outline "Roles and Responsibilities" and "Decision Making Processes". In addition, "Success Criteria" are set beforehand and are strongly linked to organisational goals (business or otherwise). Just to let you know, I work with domain experts across different unrelated industries including technology.
The role and responsibility of this person is clearly communicated to the team before the project. The person is aggressively coached before the project. In one case, live examples of note taking were provided with the note taker as a reticent participant of the meeting.
(Ex: Person A thought that 3-weeks was the agreed upon delivery date. Person B thought that "3 weeks after next Tuesday" was the agreed upon delivery date.)
Who is correct? Person A or Person B? Maybe PersonC or PersonD have insight into the issue. Regardless: the solution is to call a new meeting to clarify and finalize this "meta-issue".
-------
Since you're calling a meeting "anyway" to finalize the record, the time to finalize the notes and resolve any conflicts is during the "next meeting", whenever that is.
Bringing up those conflicts as soon as possible is important (and should be in email-form under the modern business). But determining the solution to these conflicts is the very decision-making framework that meetings are designed for.
-------
If the current record is on Person A's side "Three Weeks delivery date". Then the imperious is on Person B to bring up the misunderstanding no later than "the next meeting", wherein it is assumed that the previous record is finalized.
Ultimately, it doesn't matter "what was said" at the previous meeting. All that matters moving forward is the record of what was said.
> People get the chance to object ASAP, and are otherwise bound to the record going forward.
Agreed: the sooner objections are raised, the better. Though it is important to note when the record is finalized officially. "The next meeting" is the most logical time to finalize the record.
EDIT: I should note that I've upvoted you. I feel like you and I are on the same page, I'm just elaborating a bit.
You should surely call a meeting to clear up the conflict as soon as possible.
Another interesting angle would be, "What can we do to make the situation doesn't happen again?". One way would be to document delivery dates in the dd/mm/yyyy format. Therefore, the action item in the meeting note should be "X does Y by 13.10.2020".
This Action Item is put in real-time on the screen during the meeting itself. So, yes I agree with you that sooner is better. In my world, the sooner happens in the meeting. Therefore, I have dedicated note takers during meetings who are coached to run meetings. Most of these note takers do not even need to be individual contributors.
YYYY-MM-DD
it's only ambiguous to the degree that people adopt other "conflicting" conventions.
I wish v much for its adoption. It was established over 30 years ago.
1. ISO-8601 https://en.m.wikipedia.org/wiki/ISO_8601
My rule of thumb is if the input area is free text, and the benefit of my filling in the date is to the benefit of the form-owner, I'll use ISO-8601 dates and incentivise them to learn the standard. Join me!
To the point: according to Roberts Rules, the #1 most important item in all meetings is finalizing the meeting notes from the previous meeting (ie: Everyone agrees that the stated meeting notes are correct).
Every meeting, according to Roberts Rules, starts with an understanding that everyone at the new meeting agrees upon the summary of the previous meeting. If you cannot agree to this, then the current meeting cannot progress (because the current meeting is almost inevitably "based upon" the previous meeting). Fixing the errors in documentation is incredibly important.