Add notes from 2023-02-08 secondary (APAC) meeting (#1265)

Author: benjie

notes/2023/2023-02.md

@@ -192,3 +192,122 @@
   of edge cases.
 - Lee: we should be clear about this because the difference is subtle.
 - **ACTION** - Matt / Yaacov - tag Lee at the relevant line of code to review.
+
+# Secondary (APAC)
+
+## Agenda
+
+- Agree to Membership Agreement, Participation & Contribution Guidelines and
+  Code of Conduct (1m, Lee)
+  - [Specification Membership Agreement](https://github.com/graphql/foundation)
+  - [Participation Guidelines](https://github.com/graphql/graphql-wg#participation-guidelines)
+  - [Contribution Guide](https://github.com/graphql/graphql-spec/blob/main/CONTRIBUTING.md)
+  - [Code of Conduct](https://github.com/graphql/foundation/blob/master/CODE-OF-CONDUCT.md)
+- Introduction of attendees (5m, Lee)
+- Determine volunteers for note taking (1m, Lee)
+- Review agenda (2m, Lee)
+- Review prior primary meeting (5m, Lee)
+  - [WG primary](https://github.com/graphql/graphql-wg/blob/main/agendas/2023/02-Feb/02-wg-primary.md)
+- Review previous meeting's action items (5m, Lee)
+  - [Ready for review](https://github.com/graphql/graphql-wg/issues?q=is%3Aissue+is%3Aopen+label%3A%22Ready+for+review+%F0%9F%99%8C%22+sort%3Aupdated-desc)
+  - [All open action items (by last update)](https://github.com/graphql/graphql-wg/issues?q=is%3Aissue+is%3Aopen+label%3A%22Action+item+%3Aclapper%3A%22+sort%3Aupdated-desc)
+  - [All open action items (by meeting)](https://github.com/graphql/graphql-wg/projects?query=is%3Aopen+sort%3Aname-asc)
+- Fix ambiguity around when schema definition may be omitted (10m, Benjie)
+  - [RFC](https://github.com/graphql/graphql-spec/pull/987) - currently stage 1,
+    looking to advance
+  - [GraphQL.js implementation](https://github.com/graphql/graphql-js/pull/3839)
+- Fragment Arguments (10m, Matt)
+  - [graphql-js PR](https://github.com/graphql/graphql-js/pull/3835) is waiting
+    for review
+    - Do we need a flag? It's difficult to evaluate usage without graphql-js
+      syntax support: can we can merge as-is without a flag?
+  - [Relay has PR](https://github.com/facebook/relay/pull/4214/commits/104d1eec479b4be9b378542a246c2d5159efa2cc)
+    enables the new syntax over directives
+    - Blocker for Relay adoption within Meta is graphql-js, and therefore
+      prettier, syntax support.
+
+## Determine volunteers for note taking (1m, Lee)
+
+- Benjie
+
+## Review agenda (2m, Lee)
+
+- Looks like a short one, so I can use remaining time to address the GraphiQL
+  publishing permissions issues.
+
+## Review prior primary meeting (5m, Lee)
+
+- [WG primary](https://github.com/graphql/graphql-wg/blob/main/agendas/2023/02-Feb/02-wg-primary.md)
+
+## Review previous meeting's action items (5m, Lee)
+
+- [skipped]
+
+## Fix ambiguity around when schema definition may be omitted (10m, Benjie)
+
+- [RFC](https://github.com/graphql/graphql-spec/pull/987) - currently stage 1,
+  looking to advance
+- [GraphQL.js implementation](https://github.com/graphql/graphql-js/pull/3839)
+- [summary]
+- Have you had a chance to look at it in GraphQL Java?
+- Donna: yes, I had a look earlier and there is indeed an issue where the schema
+  appears to have a Mutation type when it should not; we'll fix it.
+- Great! Basically ready for RFC2, the only issue is there's a test in
+  GraphQL.js that I don't know why it exists and I had to do a special case
+  handling for no root operation types in printSchema to handle it.
+- Issue is that if you have a schema consisting of the type
+  `type Query {foo: String}` but that is _not_ the root query type (the schema
+  is invalid and has no operation types) then when you print it, either it looks
+  valid (because `Query` is a default operation type name) or you print it as
+  `schema{} type Query{foo: String}` but that cannot be parsed. I worked around
+  it, but I'm not sure why this test exists or what it's trying to enforce.
+- Matt: could be related to removing the query type?
+- Lee: we should make the print-parse-print loop consistent
+- Matt: it is, it'll take an invalid schema and make it valid but then it'll be
+  consistent from there on out.
+- Matt: at Meta we split the schema types into different files and parse them
+  into ASTs and merge them to build the schema.
+- [changed to Matt's topic, then circled back]
+- Benjie: thinking about this, you cannot add anything to the SDL
+  `type Query{foo: String}` to make it have no root types.
+  `type Query{foo: String} schema {}` won't currently parse. So this is an
+  invalid schema that cannot be represented in SDL; when we attempt to represent
+  it via SDL we get what appears to be a valid schema, and then the
+  print-parse-print loop is happy and consistent. So I think this is the right
+  solution.
+- Lee: I'm concerned about the `?? null` in the code, is that needed?
+- Benjie: yes, I think when you do `query.getQueryType()` it will return `null`
+  if there is no query type, however if you do `query.getType('Query')` then it
+  will return `undefined` (or maybe the other way around); so the `?? null`
+  means we consistently deal with null which makes the later
+  `queryOperationType === queryType` comparisons easier.
+- Benjie: is there an action for me to take at this point, or do we just need
+  people to review it?
+- Lee: I'll spend some time reviewing it.
+
+## Fragment Arguments (10m, Matt)
+
+- [graphql-js PR](https://github.com/graphql/graphql-js/pull/3835) is waiting
+  for review
+  - Do we need a flag? It's difficult to evaluate usage without graphql-js
+    syntax support: can we can merge as-is without a flag?
+- [Relay has PR](https://github.com/facebook/relay/pull/4214/commits/104d1eec479b4be9b378542a246c2d5159efa2cc)
+  enables the new syntax over directives
+  - Blocker for Relay adoption within Meta is graphql-js, and therefore
+    prettier, syntax support.
+- No pushback from Relay so far.
+- Before any servers have the new syntax we will require the tooling to support
+  the new syntax.
+- There's internal questions over how it works, but the syntax seems well
+  established and no-one is questioning it.
+- Lee: once something is released, people will start using it and it removes the
+  ability to iterate if need be.
+- Matt: might make sense to change the name of the flag ("fragment variables").
+  Parser would just not understand things unless it has a flag. Alternatively
+  the flag could be in the validation rather than the parser.
+- Lee: keeping the flag but renaming it seems reasonable; enables you to write
+  tests, test corner cases, Relay to use it, etc whilst still ensuring we can
+  change our minds if we need to.
+- ACTION - Matt: rename the flag and add it to the parser (that's what we're
+  doing with Relay anyway)
+- Matt: Main question remaining is around scoping behavior.