Create 2023-08-11.md

Author: david-christiansen

meetings/2023-08-11.md

@@ -0,0 +1,62 @@
+# TWG 2023-08-11
+
+[Last meeting's notes](https://github.com/haskellfoundation/tech-proposals/blob/main/meetings/2023-07-14.md)
+
+# Meta
+
+Evie is resigning; we will attempt to recruit a new member at or following ICFP. Gershom will encourage applications there.
+
+# Project Updates
+
+# Proposals
+
+## Module Naming Conventions
+
+https://github.com/haskellfoundation/tech-proposals/pull/53
+
+* Things in the threads that have not made it to the proposal text (e.g. `Experimental` as suffix rather than prefix to module names)
+* We prefer practical arguments over aesthetic ones
+* The mental model of the prefix vs suffix is that prefix suggests a logical relationship between everything there, while the suffix suggests that the contents are related to things that otherwise exist elsewhere.
+* There seems to be a consensus not to talk about the GHC API here
+* David will add a summary of this discussion as a comment
+* We think that sufficient stakeholders have been contacted
+
+
+# Other
+
+## Trees That Grow
+
+FYI Laurant left comment here https://gitlab.haskell.org/ghc/ghc/-/issues/21592#note_519447
+
+Idea for potential proposal: getting the full benefit from Trees That Grow, resulting in the AST in a library outside of GHC that GHC users and a parser that's also outside GHC. The big blocker is the user of `FastString`, a GHC string type that features interning of strings. Potential solutions: replace FastString with Text or similar (performance allowing), parameterize AST over a string type.
+
+We suggest a really minimal proposal that says the goal is a separate package, and that it has one outstanding major concern to address. 
+
+## Ways to Help Server Admin
+
+Can we pay a company to lighten the load for Haskell admins?
+
+ * Hackage and to a slightly lesser extent downloads seem to be very sensitive due to risk of software supply chain attacks
+ * Someone good at email config and migration would be really valuable
+ * Most other things are nixified - this makes it much easier to maintain
+
+Two boxes we're concerned about that aren't Hackage or downloads: 90% nixified (www entirely, other than the Hoogle stuff). These aren't updated often. There are backups (done manually).
+
+Most value seems to come from finishing the migration to the new mailman. Most of that is done but there's some open questions. If we can find a contractor who's open to taking over two nix boxes and is skilled at email stuff who can do the mailman migration and then continue to take over the Postfix migration.
+
+Skills:
+ * Mailmain
+ * Postfix
+ * Nix
+
+We could start with a contract for the mailman migration, then if they work out, move onwards to more. We should have the conversation.
+
+People to have in the conversation:
+ * Gershom
+ * Davean
+ * Bryan
+ * Ben G.
+
+Suggestion: Haskell companies will have more people who are into this. Haskell company that does Nix? John says that Obsidian did in-house email until recently, so they exist.
+
+Davean will put together a sketch of what's needed that we can use to get quotes.