docs: add meeting notes from 2022-02-23 call

meetings/2022-02-23.md

@@ -0,0 +1,86 @@
+#### Meeting from: February 23rd, 2022
+
+# Open RFC Meeting (npm)
+
+### Attendees
+- Darcy Clarke (@darcyclarke)
+- Ruy Adorno (@ruyadorno)
+- Jordan Harband (@ljharb)
+- Nathan Fritz (@fritzy)
+- Rick Markins (@rxmarbles)
+- Wes Garland (@wesgarland)
+- Owen Buckley (@thescientist13)
+
+### Previously...
+
+- [2022-02-15](https://github.com/npm/rfcs/blob/main/meetings/2022-02-15.md)
+
+### Agenda
+
+1. **Housekeeping**
+	1. Introduction(s)
+	1. [Code of Conduct Acknowledgement](https://www.npmjs.com/policies/conduct)
+	1. Outline Intentions & Desired Outcomes
+	1. Announcements
+	  - [Taking March off from Open RFCs](https://github.com/npm/rfcs/issues/538)
+1. **PR**: [#522 RFC: Option for npm diff to ignore cr at eol](https://github.com/npm/rfcs/pull/522) - @oBusk
+  - @ruyadorno 
+    - want to ratify & move forward with this flag
+    - open question is if we should make this the default behaivour?
+    - author has already added this support to `js-diff`
+  - @darcyclarke
+    - what is the default `git diff` behaivour?
+  - @ljharb 
+    - would be nice to shared config with `git` if we care about compliance/shared understanding/feature-set (ie. "mimic")
+  - @wesgarland
+    - we have the opportunity to be a bit more permissive
+  - @ruyadorno 
+    - we should probably err on the side of safeness
+    - like the idea from Jordan to possibly extend, read configs directly from git configs
+  - @darcyclarke
+    - Just worried that we might run into the types of problems we have with having both `.npmignore` and `.gitignore` to determine files on publishing
+    - **Action:**
+      - [ ] @ruyadorno to ratify 
+3. **PR**: [#519 RFC: Package Distributions](https://github.com/npm/rfcs/pull/519) - @darcyclarke
+  - **Action:**
+    - [ ] @daryclarke to set up meeting 
+4. **Issue**: [#482 [RRFC] npm should use stderr for errors](https://github.com/npm/rfcs/issues/482) - @exx8
+  - @lukekarrys
+    - had some concerns
+    - this breaks the ability for output to be passed to other commands (ex. `--json` piping to `jq`)
+    - feels weird to switch outouts based on `--json` flag
+    - don't think we should print all errors to `stderr`
+  - @ljharb
+    - only quarentee I have with `--json`  is that `stderr` is parseable `json`
+    - can't expect the error path to give you a well-formed response
+    - errors should not be considered parseable
+    - difficult to guarentee
+  - @lukekarrys
+    - agree, but...
+    - we can return `json` for errors that are recoverable (ex. registry errors)
+    - don't want to make impossible the default `logevel` of `notice`
+    - recommended path forward: 
+      - all log output go to `stdout`
+      - all error output go to `stderr`
+      - `--json` should always return `json` (in the recoverable scenarios)
+
+### Other Discussion
+
+#### Global Command Usage
+- @fritzy
+  - working on an issue where someone was told to use `npm audit` on a global package
+  - we should remove 
+- @ljharb 
+  - we should throw an error for cases when the command doesn't support it
+- **Action:**
+  - [ ] remove messaging for audit during `npm install -g`
+  - [ ] review `--global` usage for v9
+  - [ ] `npm update` should have interactive mode & updating to latest version within range is important (ex. `npm update lodash@latest --save` saves back to `package.json` vs. `npm update lodash@latest --global`)
+
+#### [Issue: #4460 - Broken lockfile](https://github.com/npm/cli/issues/4460)
+- @fritzy
+  - missing integrity values for old `package-lock.json` should warn &/or fix these
+  - warning seems sensible
+  - self-healing lockfile seems sensible
+- @ljharb
+  - would want to know if the registry I'm configured against doesn't have integrity (ie. waring would be important)