Add notes from April WG

.prettierignore

@@ -1,4 +1,9 @@
 # PRs to Working Group documents should be minimal effort - no need to force formatting compliance
-/working-group/
+/working-group/*.md
+/working-group/agendas
+/working-group/notes/2022
+/working-group/notes/2023
+/working-group/notes/2024
+/working-group/notes/*/summary-*
 # To maintain the expressiveness of the original poster, we do not auto-format RFCs
 /rfcs/

working-group/notes/2025/2025-04.md

@@ -0,0 +1,61 @@
+# GraphQL-over-HTTP WG - April 2025
+
+**Watch the replay**:
+https://www.youtube.com/watch?v=nHSixplvCc0&list=PLP1igyLx8foEz9127xc0SsabIrbTMt9g5
+
+Agenda:
+https://github.com/graphql/graphql-over-http/blob/main/working-group/agendas/2025/04-Apr/24-graphql-over-http-wg-april-2025.md
+
+Participants:
+
+- @shane32
+- @martinbonnin
+- @benjie
+
+## Watershed
+
+- The watershed was January, 2025. It is now April, should we remove it?
+- Benjie asked for some actual data. GraphQL mostly uses 200.
+- If we were to keep the watershed, it should be well in the future.
+- Aim: Merge next Thursday, based on preexisting PR approvals by shane32,
+  enisdenjo, martinbonnin, benjie.
+
+## Partial success response code
+
+- 200 for everything is a common complaint
+- With our new status code, we allow non 2xx for errors.
+- It would be good to have a non-200 status code for partial responses.
+- There is no suitable HTTP status code for now.
+- WebDav has 207 (multi-status).
+- 206 is about byte ranges. We don’t want to overload this.
+- We should allocate ours in the high 29x (294? 247?)
+- Shane: this would be useful for logging, what else?
+- Status codes are not really useful for the clients. They can deduce everything
+  from the body.
+- It’s for proxies, status monitoring, etc…
+- Is it a MUST? Is it a SHOULD?
+- Shane: how do we make sure we are not conflicting?
+- It would be good to have unified status code for future tooling.
+- Benjie: We are not supposed to allocate our own status codes. But some people
+  have done it (Twitter, 420)
+- It’s for your own backend tooling => If you choose to not do it, this is fine.
+- Martin: why do we even mandate 2xx?
+- Benjie: It’s a tradition, better for client compatibility .
+- We also want to reuse 4xx and 5xx
+- Ideally we want everyone to implement it in the same way.
+- Shane: Helps improve logging.
+- Not sure I would mandate it because it’s not on IANA’s list but that’s the
+  only real reason.
+- In all cases, having a specific code would be really useful.
+
+## Security
+
+- Merge the security note?
+
+## Triaging
+
+- If everyone wants to do some triage, let’s go for it.
+
+## Release
+
+- Aim to release together with the new spec release in July?