Add meeting notes for 2016-08-30 sync

Summary: Closes #1366

Reviewed By: josephsavona

Differential Revision: D3805396

Pulled By: wincent

fbshipit-source-id: 6821b915ee1ecccdb33ad51432289efdf3597c26

meta/meeting-notes/2016-08-30-team-sync.md

@@ -0,0 +1,90 @@
+# Agenda
+
+* Project updates
+
+Starting with this meeting, we're trying a new format. Instead of giving *individual* progress updates on what we're each working on, we're going to discuss the major *areas* of activity and our progress towards them.
+
+# Present
+
+* [@JenniferWang](https://github.com/JenniferWang)
+* [@elynde](https://github.com/elynde)
+* [@josephsavona](https://github.com/josephsavona)
+* [@kassens](https://github.com/kassens)
+* [@wincent](https://github.com/wincent)
+* [@yuzhi](https://github.com/yuzhi)
+
+# Project Updates
+
+## Relay 1:2 interop
+
+**Goal:** here is to make it possible for most components to be written with Relay 2 syntax/APIs and have them work either in Relay 1 or Relay 2. Implementation detail: use of a so-called "compatibility container".
+
+**Status:** [@kassens](https://github.com/kassens) is working on compiler for Relay 2 to Relay 1 queries. [@yuzhi](https://github.com/yuzhi) is working on implementing lifecycle methods (`shouldComponentUpdate`/`componentWillReceiveProps` etc) in the compatibility container. Goal for next week is to pick a highly used leaf component like a text with entities (emoticons, links etc) component and start converting that.
+
+**Points of contact:** [@kassens](https://github.com/kassens), [@yuzhi](https://github.com/yuzhi)
+
+## Relay 2 product integration
+
+**Goal:** here is to convert a couple of significant views in a production app which will exercise major facets of the framework such as pagination and mutations.
+
+**Status:** Have been talking with potential collaborators internally to identify products which would be good initial test beds for Relay 2. Want to make sure performance instrumentation is fully in place before we start, so that we can compare before and after numbers. Effectively blocked on that happening, but we have other work to proceed with in the meantime.
+
+**Points of contact:** [@yuzhi](https://github.com/yuzhi)
+
+## Mutations
+
+**Goal:** is to finish the API for basic server and optimistic mutations (initially not connections, then connections).
+
+**Status:** diffs landing for optimistic mutations queue and the ability to apply and rollback. Next steps are server mutations integrated and working with the queue, hoping to get everything except connection mutations implemented this week.
+
+**Points of contact:** [@josephsavona](https://github.com/josephsavona)/[@wincent](https://github.com/wincent)
+
+## Pagination
+
+**Goal:** is to support easy pagination in Relay 2.
+
+**Status:** Underlying primitives are done ("handle fields" and handlers), now need to build a higher-level pagination API on top of it with some `GraphQLRange`-like capabilities. In the absence of this you can still manually build out pagination with some manual refetching or even just rendering additional root containers. By next week should have a prototype of a simple "load more" pagination API.
+
+**Points of contact:** [@josephsavona](https://github.com/josephsavona)
+
+## Refetching
+
+**Goal:** is to have easy refetching in Relay 2, analogous to current `setVariables` API.
+
+**Status:** We have a proposed API involving a `RelayRefetchContainer` and the ability to use `this.props.relay.refetch(variables)`; just need to implement it and try it out, which we plan to start this week.
+
+**Points of contact:** [@wincent](https://github.com/wincent)
+
+## Packager
+
+**Goal:** have fast (scalable) and convenient builds for codebase using Relay 2.
+
+**Status:** No action yet, but meeting scheduled.
+
+**Points of contact:** n/a
+
+## Pokes Dashboard
+
+**Goal:** ship Relay 2 powered Pokes Dashboard to 100% of production users.
+
+**Status:** Pokes Dashboard is ported to Relay 2 but not shipped yet. We have an upstream GraphQL dependency that we are currently waiting on, but once that is done (hopefully this week) we will flip the switch, starting with employees.
+
+**Points of contact:** [@kassens](https://github.com/kassens)
+
+## Native disk cache
+
+**Goal:** collect metrics and publish internal report.
+
+**Status:** Native disk cache is working in internal app, but still need to collect the metrics (want to compare pure JS with native disk cache implementation) for internal feed app prototype.
+
+**Points of contact:** [@JenniferWang](https://github.com/JenniferWang)/[@kassens](https://github.com/kassens)
+
+## Open source
+
+**Status:** [@wincent](https://github.com/wincent) is on call this week and is merging PRs, closing issues, preparing the package releases for this week.
+
+**Points of contact:** [@wincent](https://github.com/wincent)
+
+## Relay 1
+
+**Status:** [@yuzhi](https://github.com/yuzhi) landed [a change](https://github.com/facebook/relay/commit/de95499215827667b301160588976f2d3355dee6) that makes it such that queries triggered by `setVariables` use query names based off route in which they were fetched as opposed to first route to fetch that root call. This is relevant (specifically, more accurate) for people relying on query names in their logging infrastructure.