Create 2023-06-15.md

Author: david-christiansen

meetings/2023-06-15.md

@@ -0,0 +1,84 @@
+# TWG 2023-06-15
+
+[Last meeting's minutes](https://github.com/haskellfoundation/tech-proposals/blob/main/meetings/2023-05-11.md)
+
+## Present
+ * Laurent
+ * Gershom
+ * David
+ * John
+ * Hécate
+
+## Updates on Projects
+
+### HSoC
+
+Laurent and Gershom are mentoring HSoC students. Just had first meetings. Laurent is mentoring the Haddock decoupling, and Gershom is mentoring integrating Cabal with the error index.
+
+### Security Advisories
+
+The team has been focusing on building tooling to accept reports, and emit OSVX files
+
+### Error Index
+
+ * ~15 new codes documented at Zurihac
+ * Better new user documentation
+ * Better tool to create new docs
+ * 404 page that leads to creating docs (with accept from Sam @ GHC)
+ * Server-side syntax highlighting (paving the way for diffing of examples)
+
+
+## ZuriHac trip report
+
+ * Someone approached David with the impression that a proposals process was necessary for any Haskell project that feels "infrastructure"-ish, and the process seems too hard. How can we communicate that proposals aren't necessary if not coordinating thing?
+     * Discourse post to that effect
+     * Something on haskell.org/haskell.foundation's Getting Started page?
+     * Explicit disclaimer in proposals.md that says who _doesn't_ need to write a proposal
+
+## Standard Library Reform
+
+See [draft new version of proposal](https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/proposals/accepted/050-ghc-base-libraries.rst).
+
+John was at the meeting where this was hashed out. It seems that the normative part (the specific actions to be taken) is substantially similar, but getting people together helped to paper over the other issues. Everyone seems to be OK with it.
+
+Gershom: thinks it's really good, and we should sign off on it. Question before digging into details: did it seem that the main thing that needed to happen was getting people together so they could hear and be heard? (yes). In favor of passing as is, but some specifics:
+
+ 1. Can we just not upload `ghc-internals` to hackage rather than finding a way to hide it? There seems to be no reason, other than potentially details of how Stack works, that this should be a problem.
+     - John: Source links seemed more important than haddocks (which we don't want), and missing source links might be confusing
+     - John: It's probably best that this not be part of Stackage. There has to be able to be major version breaks in `ghc-internals` for minor GHC releases. We need to have a conversation with Stackage to figure out how to make this work.
+
+2. Gershom stumbled over:
+   "It might be easy for the new security-vulnerability mechanism to also flag packages that depend transitively on ghc-internals" There doesn't seeem to actually be such a flagging tool yet - Gershom would like to propose one, but it's not there yet. Can we remove it?
+
+   - John: All the talk of warnings when depending directly on `ghc-internals` misses the fact that the real problem is from transitive dependencies on the library, and nobody sees transitive dependency warnings.
+   
+   - David: the tool doesn't exist and there aren't concrete plans yet.
+
+   - John: All the work on better CI seems similar, perhaps also tradeoffs
+
+   - Gershom: in favor of keeping, because the authors want to do these things.
+
+   - David: Is there consensus to delete that bit? (there seems to be)
+   - Laurent: Why can't `ghc-experimental` be done today?
+       - John: It could. It's a response to historical circumstances where library code to support experimental new features ended up in `base` even though the stability level is lower.
+       - Gershom: This addresses more issues, which helps make a compromise that everyone can accept
+3. David: Is this the appropriate venue for this proposal?
+    - John: The cross-cutting nature of it makes it not seem to fit elsewhere perfectly 
+4. Gershom: what about the resources request that disappeared?
+    - It looks like this will be done more incrementally without a specific need for a block of funds, but we may get requests for resources for parts of this going forward
+5. John: There was disagreement as to how feasible a "clean split" is. We'll see what happens and then we can offer resources as needed to unstick work.
+    - Gershom: Agreed - let's see what happens 
+6. David: This replaces #47 rather than revising it, right?
+    - John: yes!
+
+Next step:
+
+ 1. John gets it hashed out on the email thread, and then submits. When he submits, he'll promptly contact the Stackage curators for feedback RE hackage upload, release practices, etc.
+
+    - HF Slack is good for that, David says. #stackage or #stack-collaboraters.
+
+ 2. John can call for vote on mailing list so we are not waiting for next month.
+
+## Other Business
+
+David needs to find a new time based on our when2meet so Noon can participate (sorry!)