Recent events have pointed out a flaw in the way we have been managing the meeting notes from the Community Call. At this point, I believe we have a few options to chose from moving forward:
Make a new Google Doc (like the one I’ve used for the last few calls) as proceed exactly as before. In future, notes from previous calls could be added in as well, once recovered from the corrupted document.
Make a Discourse post with all the boilerplate from the top of the Google Doc as the original post, then put the notes from each subsequent call as a reply on that thread. If/when the notes from previous calls are recovered, add them to the “archive” Google Doc here: Combined Flang Community Call Notes Archive
Put a CombinedFlangCommunityCallNotes.md document in the repo. The intended flow would be for the call organizer to post a PR with the meeting’s agenda added to this document the day before the meeting, take notes in the document during the call, then mark the PR ready for review (or merge) after the call is completed.
I do not have a strong preference for which method to use going forward, hence I am hoping for lots of feedback so we can choose what is right for our community.
In the case of option 2, would we be using Discourse as an archive and continue using a Google Doc as a “workspace”? So the meeting agenda and notes would be in a Google Doc as they are now, attendees can add items to the agenda and notes as they can now, but those notes would then be added to Discourse?
Option 3, repo, does have an advantage of good Markdown support. Although an alternative to Option 1 with good Markdown support could be HackMD, e.g., cf. [RFC] A Provenance Model for LLVM - HackMD
Edit: I’d prefer 3 (with directory organization) > 2 (with HackMD > Google Docs) > 1 (although OK if supplementary only)
I was just thinking about the same thing. Discourse is probably not a great real-time note taking tool, but it’s convenient to see notes of past meetings. I would recommend taking notes in Google Doc, and then generate a Discourse post after the meeting.
Is “real-time” collaborative editing really needed?
If not, Option 3 keeps Flang meeting notes in the Flang repo, and prevents the data loss like we encountered with Option 1.
Going with Google Docs again does nothing to prevent catastrophic data loss from occurring again. At least with Option 3 we have redundant copies of the notes available in every clone/fork.
Discourse is the flavor-of-the month. I wouldn’t rely on it.
My preference would be 3 > 2 > 1. Besides the risk of loss for google docs, folks may have restricted access to it based on company policies or geographic location. Discourse is just the tool of choice for the time being; It has high risk of being abandoned in favour of another tool. “Pinning” these notes to source code ensures accessibility, longevity and discoverability.
With a Google Doc, attendees can add items to the agenda during the meeting. This is not uncommon. Sometimes, meetings have run long attendees have provided updates directly in the meeting notes instead of speaking to allow other topics to be discussed at greater length.
If that happens, it would be easy to migrate the notes elsewhere. (Certainly having a backup elsewhere would be a good thing.)
I think Option 3 is too heavy handed: that would mean that only people with LLVM commit privileges could update meeting notes. We sometimes have guest presenters and they would have to find someone to review and merge their meeting notes PR. And then we could drown in PRs as people would want to add more items or fix typos. Perhaps a backup/archive could be kept in a repo, but an immediate discussion around the “fresh” meeting notes should be held using a tool that’s better suited for a discussion, in my opinion.
We discussed this RFC on the special call today and here is a working idea:
Use the new Google Doc as a working document for drafting the agenda, taking notes in real-time during the meeting, and editable by everyone who can access given location and company policy restraints
Post the agenda in the Flang Slack channel the day before the meeting and ask if anyone has anything they would like to add to it. This will increase the ability of community members to contribute who are not able to access Google Docs, don’t have commit access to LLVM, etc.
Once the meeting is over and the notes are finalized, add them to a document in the repo
There is still an open question as to the best form for this
We could use one (big) running document that gets archived at the end of the year
Alternatively, we could have a new document for every call posted in a new folder for every call such that slides from presentations could easily be added into said folder
Thoughts? I would like to be able to reach a decision on this by the call next week.
I really like this idea since it is accessible to people in a wider range of organizations and locations. We should probably do this regardless of what decision is made regarding the archiving of the notes.
As explained on the call this morning, here is how I propose to resolve this:
This Google doc becomes a working document for drafting the agenda, taking notes during the call
The meeting organizer will post the agenda on Slack the day before the meeting, indicate to edit the Google document directly with additional items or other changes, and say community members should reply to the Slack post if that is not possible due to restrictions they may have accessing Google Docs due to company policies or what-have-you
flang/docs/MeetingNotes/YYYY/
files of finalized notes go in this directory, in a file like YYYY-MM-DD.md
flang/docs/MeetingNotes/README.md contains the boilerplate information, will point to the GettingStarted.md document for call information to avoid tracking in two different places
I will leave this RFC open for comment for one more week. If there are no objections by then, I will move forward with this plan. Thank you to everyone who weighed in on the discussion, both in Discourse and on the calls!