doc: add meeting notes for Feb 14 2018

doc/meetings/2017-02-14.md

@@ -0,0 +1,99 @@
+# Node.js Foundation Modules Team Meeting 2018-02-14
+
+## Links
+
+* **Recording**: https://www.youtube.com/watch?v=QURheOVmqDk
+* **GitHub Issue**: https://github.com/nodejs/modules/issues/25
+* **Minutes Google Doc**: https://docs.google.com/document/d/17T8ZeF2mUPffiDvulqd_HqD_JrTNaf8ch2dFT1hMfD0/edit?usp=sharing
+
+## Present
+
+Benjamin Gruenbaum (@benjamingr)  
+Bradley Meck (@bmeck)  
+C J Silverio @ceejbot  
+Daniel Rosenwasser (@DanielRosenwasser)  
+Gus Caplan (@devsnek)  
+Jeremiah Senkpiel (@fishrock123)  
+Gil Tayar (@giltayar)  
+Guy Bedford (@guybedford)  
+Rebecca Turner (@iarna)  
+James M Snell (@jasnell)  
+John-David Dalton (@jdalton)  
+Lin Clark (@linclark)  
+Wassim Chegham (@manekinekko)  
+Matt DuLeone (@mduleone)  
+Michael Dawson (@mhdawson)  
+Myles Borins (@mylesborins)  
+Andrea Giammarchi (@WebReflection)  
+Wesley Wigham (@weswigham)  
+Zack Schuster (@zackschuster)
+
+## Agenda
+
+### Announcements
+
+### nodejs/modules
+
+* How often and when should we meet? [#2](https://github.com/nodejs/modules/issues/2)
+  - Meeting doodle - https://doodle.com/poll/vdb8cgz48q3zzt2t - Default is in EST 4PM
+  - **ACTION ITEM FOR MYLES**: Email people about finalized time on Friday & add to Node.js Google Calendar 
+* Scope of team [#17](https://github.com/nodejs/modules/issues/17)
+  - Not chartering immediately - will come later down the line
+  - Should we expand scope to include CJS components
+  - Mention of a few issus by Bradley. Seems like these are EJS issues as
+           Well.
+  - CommonJS is frozen, we cannot table issues that will affect external
+            behaviour
+* Managing Signal to Noise [#15](https://github.com/nodejs/modules/issues/15)
+  - Myles to document “Discussion” Tag mechanism
+* Governance and Membership Requirements [#8](https://github.com/nodejs/modules/issues/8)
+  - Do we need more time than 48 hours for approving PRs?
+    - Some say yes.
+    - We have a very large group; much of the time members may be caught off guard. Perhaps we need some sort of quorum.
+      - Maybe a way to manage engagement?
+      - Sure, but PRs are the least concerning thing. The points of conflict are typically not code changes though.
+    - Just to clarify, when we talk about PRs, we’re typically talking about non-code based PRs that pertain to this group.
+  - So do we want a quorum-based decision process for this repo?
+    - Action item: Bradley will document this quorum policy.
+      - If we have no dissenters, move forward on a given decision.
+        - I.e. decision making is based on “tacit approval” - silence means approval by default
+      - When necessary (e.g. objections come up), quorum is 50% of active members of the working group.
+        - (Q: what is active?)
+          - We expect membership activity to taper off, so whoever is currently still active.
+  - What is explicit approval?
+    - Something as simple as “LGTM”, :+1:, etc.
+  - How do we track “active” participants?
+    - Our most recent metric has been “did you fill out the form for this meeting?”
+    - If someone isn’t active and just shows up for a single decision, is that fair?
+    - Do we track engagement by the tracker or by meetings?
+    - Does interest in a set of specific domains imply inactivity?
+      - No, that’s not quite what the concern is about.
+    - How about “if in the first two months, we see a lack of activity, we ask the participant to step to observer status?”
+      - That can be an extremely sensitive topic. We should come up with something explicit.
+  - Conclusion: continue discussing this on the issue tracker
+* Online Module Summit [#9](https://github.com/nodejs/modules/issues/9)
+  - Really great knowledge-sharing exercise discussing topics we feel are important.
+  - That way anyone who can’t participate can catch up with it.
+  - Conclusion: Bradley will plan this out.
+* Guiding Design Principles [#11](https://github.com/nodejs/modules/issues/11)
+  - Is there a difference between our design principles and our scope.
+  - Bradley: “I think they’re very different - our design principles give us our goals”
+    - Our scope is what we’re allowed to do.
+  - Jeremiah: “Is this not different from the goals document?”
+  - Conclusion: kick this back to the issue tracker
+* initial GOALS declaration [#23](https://github.com/nodejs/modules/pull/23)
+  - Bradley: don’t want to pull this in yet.
+    - Also, request for clarification from Webpack.
+    - Will discuss further.
+  - Wesley: Should have an explicit rationale for why we’ve established each goal 
+    - Yes, let’s add that to the PR.
+
+## Q&A, Other
+
+No questions for this week.  
+
+## Upcoming Meetings
+
+* **Node.js Foundation Calendar**: https://nodejs.org/calendar
+
+Click `+GoogleCalendar` at the bottom right to add to your own Google calendar.