Add notes from January secondary meetings (#1245)

Author: benjie

notes/2023/2023-01.md

@@ -207,3 +207,212 @@
 - Michael: the aggressive merging feels more GraphQL-y
 - Rob: complexity is not fetching things again just because they’re deferred.
 - Rob: you mentioned “id”, Lee, I’m not totally sold in either direction.
+
+# Secondary - APAC
+
+## Agenda
+
+1. 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)
+2. Introduction of attendees (5m, Lee)
+3. Determine volunteers for note taking (1m, Lee)
+4. Review agenda (2m, Lee)
+5. Review prior primary meeting (5m, Lee)
+   - [WG primary](https://github.com/graphql/graphql-wg/blob/main/agendas/2023/01-Jan/05-wg-primary.md)
+6. 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)
+7. [Licensing & final legal sign-off for GraphQL Scalars project](https://github.com/graphql/graphql-wg/issues/1206)
+   (5m, Donna)
+8. [Fragment Arguments](https://github.com/graphql/graphql-spec/pull/865):
+   Identify Open Concerns to Address (known concerns below) (10m, Matt)
+   - Do we allow shadowing global variables?
+   - PR with Variable Definitions instead of Fragment Argument Definitions.
+   - Do we need PR Reviews to know if there are other concerns?
+   - Maybe: additional graphql-js PR to use local scope, aka graphql-spec
+     algorithm, rather than visit replacement?
+
+## Review Agenda
+
+- Updates on things from first-week wg (see
+  [https://github.com/graphql/graphql-wg/blob/main/agendas/2023/01-Jan/11-wg-secondary-apac.md](https://github.com/graphql/graphql-wg/blob/main/agendas/2023/01-Jan/11-wg-secondary-apac.md))
+
+## Review previous meeting's action items
+
+- Andi: Benjie had validation Q for default value handling, GraphQL Java now
+  implements all default value validation
+- Andi: needed additional function for scalars value to AST
+- Influenced custom scalar work
+
+## Licensing & final legal sign-off for GraphQL Scalars project
+
+- Waiting for Lee
+- Spend time in meeting getting to done.
+- License:
+  - MIT License (it’s code not spec text). Need to add that because scalars is
+    code, but owfa is for spec text. Weird reasons why different. Need template
+    about copyright person who wrote, but open to all
+  - Andi: OWFA is ideal as mostly it’s spec, even though we have some code.
+    Value is spec not code
+  - Lee: Will say any code is MIT, any spec is OWFA. Will do this right after
+    call
+- Donna: in custom scalars section of spec, could link to GraphQL Scalars
+- Andi: spread word, use it, look into it, let’s get value out of it
+- Lee: will pull down now
+
+## Fragment Arguments Open Concerns
+
+- Extra thing: open new PR to kill and make new one to help improve context
+- Discussion about how we do it on the client (expanding fragments as templates)
+- Worthwhile to treat runtime performance of validation steps as legitimate
+  concern
+  - Could we dream up degenerate text that causes perf issues? Does this create
+    a new category of these things? Would be good to have a paragraph or two
+    explaining why we aren’t worried about it.
+
+# Secondary - EU (2023-01-19)
+
+## Agenda
+
+1. 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)
+2. Introduction of attendees (5m, Lee)
+3. Determine volunteers for note taking (1m, Lee)
+4. Review agenda (2m, Lee)
+5. Review prior primary meeting (5m, Lee)
+   - [WG primary](https://github.com/graphql/graphql-wg/blob/main/agendas/2023/01-Jan/05-wg-primary.md)
+6. 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)
+7. Defer/Stream updates (20m, Rob)
+   - [Remove labels and merge deferred fragments under the same object](https://github.com/robrichard/defer-stream-wg/discussions/64)
+   - [Deduplication of deferred fields](https://github.com/robrichard/defer-stream-wg/discussions/65)
+8. Discussion of
+   [Backward Compatibility](https://github.com/graphql/graphql-wg/discussions/1232)
+   (20m, Roman)
+
+## Review prior primary meeting
+
+- Talked about fragment arguments, need to resolve naming around arguments or
+  variables
+- Discussion about PR’s for the spec being approved but not merged; when someone
+  approves they should make the next steps clear, e.g. approved and should be
+  merged, approved but needs more feedback from other TSC members, etc.
+- Default value validation status checks
+  ([https://github.com/graphql/graphql-js/pull/3814](https://github.com/graphql/graphql-js/pull/3814))
+- Defer/stream updates
+
+## Defer/Stream updates
+
+- Summary: clients identifying streams/defers being in progress/completed.
+- Rob: I've broken the
+  [#52](https://github.com/robrichard/defer-stream-wg/discussions/52)
+  discussions up into separate issues.
+  - Remove labels entirely
+    [#64](https://github.com/robrichard/defer-stream-wg/discussions/64)
+    - Ivan: If we have initial response and one big defer per path then you can
+      live without labels, but labels are a nice feature - they make the client
+      life easier and allow us to do more complicated stuff later.
+    - Michael: I don't see the use cases for labels, could you expand?
+    - Ivan: currently we'd only get one defer per path, but with labels you can
+      ship data as you want and just mark when certain labels are resolved.
+    - Michael: but it reintroduces all the label issues?
+    - Ivan: we can use labels in a different way than what we proposed
+      previously; I'll open a separate issue to discuss this.
+    - Hugh: add them to #64
+    - Yaacov [chat]: labels allow you to declare fulfillment of defers at the
+      same path individually => but what we said previously is that we would
+      enable this eventually with fragment aliases
+    - Rob: a single defer could correspond to multiple responses, and the label
+      would indicate once all the responses mean that that label is completed.
+    - Ivan: exactly: server ships stuff when it's ready - shipping fields
+      separately or batching - then label indicates that you have everything
+      that you need to satisfy the fragment.
+    - Michael: we're hoping to solve this with fragment aliasing instead, then
+      you would not need the label.
+    - Rob: the important thing to me here is changing the contract that you can
+      have one defer per path.
+    - Ivan: Apollo Kotlin works on a merged tree of all the payloads, it doesn't
+      matter how it's received (which payloads have which fields) - it just
+      matters if the data is complete or not [for a label].
+    - Ivan: this proposal splits the idea of the label and the shape being
+      paired - the shape can be split and delivered in multiple parts, and then
+      signal when it's complete.
+    - Ivan: reason: deduplication and allowing details at the same path to be
+      resolved in different phases
+    - Yaacov: but we may be able to solve that in different ways.
+    - Ivan: you're right; deduplication is the main one for me.
+  - Deduplication of deferred fields
+    [#65](https://github.com/robrichard/defer-stream-wg/discussions/65)
+  - Include an indication of upcoming payloads in response
+    [#66](https://github.com/robrichard/defer-stream-wg/discussions/66)
+
+## Discussion of Backward Compatibility
+
+- Roman: Sometimes "backwards compatibility" gets in the way - if someone
+  mentions that then it can stop progress..
+- Related discussion:
+  [https://github.com/graphql/graphql-wg/discussions/1232](https://github.com/graphql/graphql-wg/discussions/1232)
+- Benjie: deprecated directive doesn’t mean the thing has to go away, or that
+  there is going to be an incompatible change
+- Benjie: I do like the suggested new wording: “@directive directive helps to
+  manage the gradual evolution of application schema, giving an advanced warning
+  to clients about upcoming changes in the schema.”
+- Ivan: I suggest "deprecated" discourage usage in a new client and notify old
+  client to migrate
+  - so no mention of compatibility
+  - because it's up to a server maintainer to decide on such a policy
+- Benjie: re: deprecated, it doesn't mean "it might go away," it means "avoid
+  using this." It _might_ mean that it's going to go away, but that's up to the
+  schema implementer. It might just mean there's an alternative field/pattern to
+  use instead.
+- Backwards compatibility explained in
+  https://github.com/graphql/graphql-spec/blob/main/CONTRIBUTING.md#guiding-principles:
+  - Once a query is written, it should always mean the same thing and return the
+    same shaped result. Future changes should not change the meaning of existing
+    schema or requests or in any other way cause an existing compliant GraphQL
+    service to become non-compliant for prior versions of the spec.
+  - Folks agree with this
+- Moving conversation to talk about suggested basic principles for advancing the
+  spec (from Roman):
+  1. Capabilities: do not remove, add only. Do not change, extend only
+  2. Restrictions on existing elements: never add one, but removing restriction
+     should be OK.
+  3. Presumed some tolerance of implementations to unexpected extra elements -
+     do we mention it in the spec?
+  4. Primary concern with existing end apps and their GraphQL schemas and
+     queries;
+  5. Much less concern with libraries and tools, just publish spec draft early
+     enough.
+- Yaacov: so that means there can never be any new GraphQL Types?....; That
+  can't be interpreted by old GraphiQL as an old type?
+- Benjie: It's a _should_, so basically care must be taken. GraphiQL _should_
+  ignore types it doesn't understand, in the same way that that apps should
+  expect new types to be added to a union.; However changing that an input
+  object is no longer input-only would be an unexpected change rather than a new
+  type. In general a new type is actually preferred over tweaking existing
+  types.
+- Ivan: Future changes should not change the meaning of existing schema
+- Benjie: conversation is getting a bit convoluted between backwards and
+  forwards compatibility
+
+## Update on Fragment Arguments
+
+- New discussion placeholder:
+  [https://github.com/graphql/graphql-wg/discussions/1239](https://github.com/graphql/graphql-wg/discussions/1239)
+  - Questions, comments, concerns go here
+- Making progress, would love to get feedback on
+  [graphql/graphql-js#3835](https://github.com/graphql/graphql-js/pull/3835) and
+  [graphql/graphql-spec#1010](https://github.com/graphql/graphql-spec/pull/1010)
+- Matt is working with the Relay team on making sure the solution / approach is
+  feasible