Level up our notetaking skills 📝

[daviddias]

As the project grows and more verticals are tackled, it is important to remain in sync. One really good way to achieve this by having amazing notes of when decisions are made. To achieve this we need two things:

• a) We need to ensure that notes are taken in the first place
• b) We need a review to ensure that others (people that weren't in the meeting) understand exactly what was decided and the implications of it.

To take the first stab at this, I went ahead and added notes from an offline convo that had decisions and conclusions being made, you can see it here: https://github.com/ipfs/pm/pull/492. Please review :)

The end goal should be that anyone coming to the project at a later time, should be able to understand how the project evolved and what is the state of things by reading all the notes from the discussions present in https://github.com/ipfs/pm/tree/master/meeting-notes.

[daviddias]

I've reopened this issue to get us to adopt again good practices on rotation of notetaking during our calls. Taking notes is one essential skill of a well functioning async team and we are all a giant async team :)

[daviddahl]

Back when I edited a spec on a W3C working group, we used an irc bot to scribe each meeting. The output was quite a nice representation of what was discussed in the meeting.

https://dev.w3.org/2002/scribe/scribedoc.htm

There is a new node logs -> minutes converter as well: https://github.com/w3c/scribejs

[terichadbourne]

A few thoughts:

On occasions when speakers choose to share presos in calls, it would be great to get a link to those slides added to the meeting notes for a deeper dive than what a notetaker is able to capture. At the very least, the speaker can help share links to include in notes.

When I take notes on someone's preso, I like to ping them a link to the notes afterward and invite them to make any edits needed for accuracy or completeness, particularly since I don't always have the right vocabulary myself to capture some technical concepts.

When choosing notetakers, keep in mind that a notetaker that has a smaller technical vocabulary or less exposure to a project than the presenter of a demo may have trouble (or at least imposter syndrome) taking detailed notes. Consider finding a more technical notetaker if you can predict that need in advance for a specific preso. However, it's also a great idea to encourage speakers to take a step back and explain any acronyms or underlying concepts, which will help both a diverse audience and the notetaker.

Don't forget to ask folks to add their own names to the attendee list. It's hard for a notetaker to do that while focused on the content of a call, and people's Zoom names don't match their GitHub usernames.

[daviddias]

Good points @terichadbourne! I made some updates to the #813 weekly template in light of them. There is still something more needed in the whole call prep dance though. Ideally, we would always publish the recording after with respective slides, preferably through our social network accounts (i.e. twitter) and a blog post.

On the topic of leveling up our notetaking skills, I would like to standardize in how we take notes across the org. I'm typically in favor of experimentation, but the fact that each team uses a different tool and different location to announce the meeting, zoom url and notes makes it really hard to keep track and follow up on the threads started during that call.

[daviddias]

@pkafei if we were to standardize notetaking this month? Would the tooling for it be something you are available to prioritize to finish at the same time? ref https://github.com/ipfs/team-mgmt/issues/730

[pkafei]

@daviddias

When you say standardize note taking do you mean provide a universal template?

I haven't worked on the note taking feature yet, but would like for us to come to an agreement about where we should keep the notes and how they should be maintained.

Some of our options include Google Docs and CryptoPad. We could also try to keep our notes in PeerPad and dog food one of our apps.

[daviddias]

@pkafei what I have in mind is:

• Where notes get taken (single tool, make it familiar to everyone)
• Baseline template (moderator, notetaker, participants, agenda, notes)
• Baseline preparation (make the pad available 4+ days in advance and notify interested parties)
• Automated note capture to github (post the meeting, automatically submit the PR)

Cryptpad and PeerPad have special privacy issues that we appreciate as a community. Cryptpad is more baked but PeerPad is close to prime time too.

[terichadbourne]

@daviddias Are you thinking of using this standardized approach for any meetings that are not open to the public, or only ones that are? My impression was that the IPFS community is trying to work in the open, so it's unclear to me what the benefit is of using something like CryptPad over a more familiar tool like GoogleDocs, which I'm inclined to advocate for. Could you say more about what benefit those tools offer?

As is my job as a community manager, I want to make the case for the easiest possible onboarding experience to welcome people new to our calls, including those who are not developers. My personal feelings based on my experience with 4 or 5 different weekly syncs within the IPFS space:

1. Any tool that uses markdown instead of working like a standard word processor is inherently offputting to non-developers, and we need non-developers involved in order to succeed at community growth. Someone stepping in off the street will be more comfortable with Google Docs that with GitHub or CryptPad, for example. (It's possible I actually mean HackPad, but I'm thinking of one with a markdown editor on one side and a more human-legible preview on the other.)

2. I consider it very unfriendly to the user to make them go to more than one place to find the links needed to participate in a call. My favorite weekly syncs are the ones where the calendar invite includes a consistent Zoom link and a consistent meeting notes link. I believe a user should not have to visit Slack or IRC to find the information I need to join a call, and I've been pleased to see some of the meetings changing their procedures to remove that step from the process. Having to visit a GitHub issue at a consistent link to find a new one-time-use link to meeting notes, thought less bad than having to join Slack or IRC, is still an unnecessary nuisance for attendees in my opinion.

3. I currently prefer the meetings that are using a Google Doc to collect agenda items pre-call and meeting notes during the call, with all instances of a call represented in a single doc so I can easily catch up without hunting down old links to separate documents for each meeting, as has been my experience for meetings using CryptPad, etc. I'm not opposed to later copying these to GitHub (the meeting notes folder in ipfs/team-mgmt) for posterity if needed.

4. I'd like to see us prioritize the user experience for new community members and non-developers over the time savings provided by automatic transfer of notes to GitHub. If, for example, we could only figure out how to make the archiving of notes happen automatically in a system that required meeting attendees to take multiple hops through links to join a call, use tools that feel foreign to them, or acquire new skills in order to participate in our meetings, I'd push for WG leaders to keep the current weekly inconvenience of manually transferring notes to GitHub instead of creating or perpetuating a system that makes it inconvenient or difficult for a newcomer to attend the meeting.

5. I'm not opposed to using a P2P, IPFS-based notetaking tool if it addresses the concerns I've laid out above. However, if we choose to use a new tool for the sake of dogfooding, or as a matter of principle for proving decentralized systems work, and if we do that before the specific tool is ready to support our needs and provide a user-friendly experience to new community members, we risk alienating new folks and discouraging community participation or faith in the potential of the technology.

6. Should we be sorting our archived meeting notes differently? It's currently possible to direct someone to a YouTube playlist to find all the recordings of a particular call, but not to a folder of archived meeting notes for a particular call, since the organization of meeting notes is by date and you need to look at the filename to see which meeting is referenced. Perhaps someone could create a little tool that lets you choose a particular meeting and then see all past meeting notes and videos available for it, sorted by date? This would depend on us using consistent document naming in GitHub, as we've been striving to. (This is a nice-to-have for me, not at all a requirement and much less important than the concerns listed above.)

[pkafei]

We need to revisit the scope of the automation tool. I will admit that it wasn't initially clear, and didn't offer a transparent spec on what problems the community sync tool would address.

1. IRC and Github Issue Announcements: The Sprint Helper Bot makes Github Issues which announces upcoming Weekly Syncs.

2. Automatically Create PR: Sprint Helper Bot will allow the note taker to send the CryptoPad notes to the team management repo and create a PR within the Sprint Helper Bot interface

3. Standardize Template: Sprint Helper Bot will have a standardize template that all teams will use to facilitate note taking- there will be less mental overhead on the best way to format notes.

I'm open to keeping these notes on Google Docs. That being said, I would like for us to come to an agreement on where the notes should be taken and agree on standard note format.

@terichadbourne I agree that we shouldn't limit our Weekly Sync announcements to IRC or Github Issues. It wouldn't be a heavy lift to automate announcing our Weekly Calls on platforms like Twitter, and Reddit. I would argue that we should also make ourselves more known on Steemit as well. Also LinkedIn is amazing for attracting non-devs.

[daviddias]

CryptPad over a more familiar tool like GoogleDocs

There are multiple arguments: One is open source, it doesn't require user accounts, preserves people's privacy, aligned with the Encrypted Web Goals

The statement also makes the assumption that Google Docs is more familiar to all our communities. Perhaps for the majority given Google's pervasiveness, but not for all special focus communities or geographies (i.e. China).

I'd like to see us prioritize the user experience for new community members and non-developers over the time savings provided by automatic transfer of notes to GitHub.

Agreed. Although automation can save us all.

It's currently possible to direct someone to a YouTube playlist to find all the recordings of a particular call, but not to a folder of archived meeting notes for a particular call,

Both have their advantages. Notes can be text searched, videos can't (unless we get transcripts, which would be great).

Another thing to consider is meeting location. For example, some Working Groups store their notes in other repos/docs.

Today, I literally have to have a table of WG -> Location for notes which includes multiple urls, tools and formats so that I can be able to follow up what's up.

It wouldn't be a heavy lift to automate announcing our Weekly Calls

And in our Website (ipfs.io) too! :)