doc: add missing WG API notes (#246)

wg-api/meeting-notes/2020-02-03.md

@@ -0,0 +1,32 @@
+# API Working Group
+
+## Date: 2020-02-03
+
+### Attendees
+
+**Members:**
+* **@jkleinsc**
+* **@itsananderson**
+* **@zcbenz**
+* **@vertedinde**
+* **@loc**
+* **@nornagon**
+* **@marshallofsound**
+
+### Agenda
+
+* [feat: add aggregated renderer-crashed event with all affected webContents]( https://github.com/electron/electron/pull/20006)
+  * milan not present, no discussion
+* `clipboard.availableNativeFormats()` 
+    * https://hackmd.io/@itsananderson/SyAdeg8zI/edit
+    * https://github.com/electron/governance/pull/229
+    * can we expose these as constants? since they don't change
+    * https://source.chromium.org/chromium/chromium/src/+/master:ui/base/clipboard/scoped_clipboard_writer.cc;l=22-24;drc=faba093c50cc158fe7fbf28534798673489dc0cd?originalUrl=https:%2F%2Fcs.chromium.org%2F
+    * https://chromium-review.googlesource.com/c/chromium/src/+/1729965
+    * Outcome:
+        * Revise the RFC with:
+          1. Use constants?
+          2. What's the relationship with the existing clipboard APIs? Can we write both simple + buffer formats together?
+          3. Evaluate and cite real-world use cases
+* Extensions API: https://github.com/electron/electron/issues/19447
+  * To review async & discuss @ next meeting

wg-api/meeting-notes/2020-03-09.md

@@ -0,0 +1,35 @@
+# API Working Group
+
+## Date: 2020-03-09
+
+### Attendees 
+
+* **@nornagon**
+* **@zcbenz**
+* **@jkleinsc**
+* **@itsananderson**
+* **@codebytere**
+* **@MarshallOfSound**
+
+### Followup
+
+* Extensions API
+
+### Agenda
+
+* Properties - should we use getters and setters or functions?
+  * **Verdict** - we will make both available to consumers for [primitive](https://developer.mozilla.org/en-US/docs/Glossary/Primitive) properties.
+  * Boolean primitives will have functions taking the form `setX` and `isX`, while other primitives will have functions taking the form `setX` and `getX`.
+  * We will remove standing properties deprecations
+
+* Open Spec Proposals
+  * **Verdict:**
+    * Open spec proposals block their implementations being merged
+    * Proposals can be updated after merge so long as no significant semantics change
+    * Proposals can be merged once they've been made sufficiently visible to stakeholders and have at least 2 reviews
+  * We should make reviewing open proposals a standing agenda item.
+
+## Action Items
+
+- @codebytere to de-deprecate existing properties deprecations
+- @zcbenz to update best practices API doc