Skip to content

Latest commit

 

History

History
160 lines (144 loc) · 15.5 KB

2021-02-04.md

File metadata and controls

160 lines (144 loc) · 15.5 KB

GraphQL WG Notes – February 2021

Watch the replay: GraphQL Working Group Meetings on YouTube

  1. Agree to Membership Agreement, Participation Guidelines and Code of Conduct (1m, Lee)
  2. Introduction of attendees (5m, Lee)
  3. Determine volunteers for note taking (1m, Lee)
  4. TSC meeting (15m, Brian, Lee, TSC members)
    • Upgrade GraphQL Specification membership documents from v4 to v5 (TSC VOTE)
  5. Review agenda (2m, Lee)
  6. Google Summer of Code this year? (5m, Brian)
  7. Review previous meeting's action items (5m, Lee)
  8. Promoting and documenting spec release (5m, Brian)
    • Newly created foundation marketing committee
    • Collecting content/items already written (new features, community perspectives)
    • Finding and closing gaps in the narrative
    • Please send anything you've written already to Lee or Brian

Determine volunteers for note taking (1m, Lee)

  • Alan
  • Benjie
  • Eloy
  • Stephen

Review agenda (2m, Lee)

TSC meeting (15m, Brian, Lee, TSC members)

  • The GraphQL Foundation was set up under the Joint Development Foundation Projects (version 4).
  • Version that we used when we set up makes it difficult to release a new version quickly
  • requires signature from every contributor to release
  • LF has released V5
    • sign spec once -> no more signatures required for release
  • Important for our group as we have many different groups working simultaneously
  • TSC can upgrade docs with a vote (V4 -> V5); we needed a substantial number of TSC members to be present
  • Concerns: 30 day notice period
  • TSC has received documents to review; haven't raised any questions.
  • Lee: sounds good; any questions?
  • Evan? Are the documents available somewhere?
  • Brian: yeah, they're now merged into the GraphQL-wg repo. Existing signatures are still valid.
  • VOTE
    • Dan moved to adopt the V5
    • Matt seconded
    • Large number of "ayes", no opposed or abstained
  • Reminder: we have a bot that checks on PRs to see if the documents have been signed or not. You can sign as individual or have the company sign it for you. If you have any issues, reach out to Brian Warner; the CLA bot is being enabled for all repos now.
  • ACTION - Brian: graphql/foundation github repo, has v4 of the JDF file
  • ACTION - Lee: GraphQL WG readme file links to the foundation repo; link to new folder with explainer. [COMPLETE]
  • Brian: One great feature is that people will be led through the flow of signing the documents when they PR to join a meeting.
  • TSC meeting closed [17:19 UTC]

Google Summer of Code this year? (5m, Brian)

  • Brian: We did Summer of Code last year
  • Brian: The application period is opened again and Brian is asking for suggestions for projects
  • There was discussion last year about how mentorship is a way that the foundation wants to support the GraphQL projects - we would like to have at least 3 (?) interns per year.
  • Lee: Last time this came up, it was during a board meeting but this time we’re opening it up because there are a lot of people in the working group calls, working on various projects
  • Last summer we got a lot of value out of this (Ivan?); we should double down, but spread out across more projects: GraphQL-js, GraphiQL, community projects, etc.
  • Ivan: last year I mentored Amar; one thing to note is that project ideas are just suggestions - students can add project ideas themselves, or you can suggest to them directly. Last year it was 300 hours, but this year closer to 180 hours; makes it easier for maintainers.
  • Ivan: GraphQL-js intern last year created an experimental parser.
  • Ivan: GSoC helped many ways; helped onboard new developers and maintainers; but also helped me personally because I didn't have experience mentoring but it taught me how to do that.
  • Ivan: can be applicable for existing contributors.
  • Ivan: we failed to create good communication with applicants last year - we had a lot of emails with simple questions, this year we should write documents to answer them - prepare more for communicating with applicants - we had 50 or 70 applicants.
  • Uri: Regarding GSoC; at this stage of the graphql-js project, Ivan's time is the most expensive time we have, and there's a huge project we're working on (TypeScript migration) which is holding up a lot of other projects, so we should be very careful that (although GSoC is very important) maybe others can be the mentors so that Ivan can keep focussing on getting the TS migration done so that we can keep pushing things forward.
  • Uri: it's important to bring new contributors to the code, but there's a lot of existing contributors we can encourage too.
  • Lee: It’s a good point. I hope we can find a compromise.
  • Lee: my goal for GSoC is to create new members of this community and long-term contributors. We'd like them to stick around for the long-haul.
  • Lee: The other thing I’d like to see is to see if one of those students joins one of these meetings. Last time, our students did not have a chance to meet the people in this meeting and that is a shame.
  • ACTION - everyone (champion: Lee?): think about what potential projects there are.
    • We can consider things that are core parts of the GraphQL community - not just foundation projects
  • Andi: what's the time commitment involved in mentoring someone?
  • Ivan: they ask you to volunteer 5 hours per week at a minimum. In practice it depends on the project, one thing is that you can organise a lot of this work asynchronously - ask student to open a branch and then monitor their commits. This year they're doing a shorter period (from 3 months down to a month and a half or something)
  • Brian: it's 10 weeks long with 18 hours per week from the mentee.
  • Lee: having two synchronous check-ins and time for code review works well. Two thirty minute sessions in a week along with code review tends to work well.
  • Uri: where do we submit projects?
  • Lee: there's a channel in the slack; and the link in the agenda (https://github.com/graphql/foundation/tree/main/mentorship/2021/gsoc) is to a project template. Copy the template, fill out the idea (doesn't have to be super in depth) and save it as a markdown file in that folder (raise a PR).

Promoting and documenting spec release (5m, Brian)

  • Newly created foundation marketing committee
  • Collecting content/items already written (new features, community perspectives)
  • Finding and closing gaps in the narrative
  • Please send anything you've written already to Lee or Brian
  • Brian: now we have v5 agreed, it should be easier to cut the release. We had a foundation marketing meeting (these will be monthly from now on) to help prepare for the spec release. If you've documented a feature or are interested in writing something up please let me (Brian Warner) or Lee know to help us build a narrative around the release.
  • Lee: why are we doing this? Reference implementations and community implementations tend to track the draft, so the "cut" spec is mostly an artifact. What's the value beyond the legal process? Having a moment in time to look at the work that went into it and reflect on it - "let's look back at all the work that's gone into GraphQL in the last 18 months." It's to let the people who've been doing the work talk about what doing the work was like, what it enables, why. What's it like when you find an ambiguity and want to write a spec change to solve it?
  • Lee: What we can do is create a schedule that draws attention to these blog posts
  • Lee: We are just going to collect the ones that we’ve written and a stories that we want to tell and aggregate them
  • ACTION - everyone: if you've written something like this, we've not been tracking it, please ping Lee or Brian!
  • ACTION - everyone: write stuff! Encourage others to write stuff! Or promote stuff others have written!
  • ACTION - Lee and Brian: write a list of the things you definitely want covered
  • Evan: what about the RFCs in the final stages - before or after the cut?
  • Lee: I'm going to try and squeeze them in. I've been using tag:editorial or tag:stage2 to track this, so if they don't have these tags but should let us know!
  • Evan: I think they all have action items assigned to.
  • Ivan: stream/defer is experimental; we should explain in a blog post about the new release about stream/defer, why it's experimental - still collecting feedback. Same thing with input unions, a lot of work has been done but is not yet visible. Good to talk about the current progress of these proposals.
  • Lee: good point; I do plan to write a "release notes" but I really like this suggestion - "we've done a spec cut and here's all the stuff in the spec, but here's also all the stuff we're still working on."

Review previous meeting's action items (5m, Lee)

Ready For Review:

  • 507: Moving the @deprecated directive on Input Fields RFC to Stage 2
    • [Lee] I’m going to move this to Stage 2
    • [Lee] @Ivan is deprecation of input values up to date in graphql-js?
    • [Ivan] Only negative feedback was because of misused graphql-js, so we’ve merged it approx. 6 months ago.
    • Ivan needs to check the validation rule
    • ACTION - Ivan and Lee - make sure everything is done on this.
  • 550: [Ivan,Uri] Send removal notices to existing GraphQL.js contributors
    • [Ivan] Did not get to this, so let’s do it the fast way [as discussed in the previous meeting.
    • [Lee] If somebody had commit access and is now surprised they no longer have it, they can just ask and immediately receive back access. So we can just remove everybody now.
    • Ivan will do so tomorrow.
    • [Ivan] One thing to consider is that they will need to be removed from the org and thus will be removed from other repos as well.
    • [Lee] We can consider doing 2 passes, one where the people that have clearly not committed are removed first.
    • [Ivan] We should also consider the number of people that have push access for the graphql-js npm package, which might be more of an issue than signing the agreement.
    • [Lee] We require 2fa to push the graphql-js npm package, unsure about graphiql.
  • 586: [Benjie] Ping Apollo about Apollo's schema store
    • Benjie: I have done so but Apollo doesn’t have anything in place that will allow them to determine whether the schemas are public or not
    • Benjie: It’s a no go for the default value coercion project that this issue was originally intended for
    • Benjie: Perhaps in the future we will be able to receive access to a subset of the data, by means of asking access to this data for GraphQL org research.
    • Benjie: Can be closed
    • Ivan: There should be a tool for anonymization of schemas. This could even be a good project for GSoC
    • Benjie: They were cautious about how the data could be de-anonimized.
    • Andreas: Something in this space already exists, albeit early stage [link needed]
  • 587: [Kewei] Explain why initialCount behaves as it currently does
  • 588: [Rob] Make initialCount nullable (GraphQL.js and spec)
    • Benjie: Rob has mentioned that he has updated the spec to reflect that
    • Can be closed

Other open actions items:

  • 581: [Mark] Schema Coordinates: Add functions to graphql-js for schema coordinate parsing/printing
    • No update
  • 583: [Ivan] Review "RFC: Assert subscription field is not introspection.
    • No update
  • 584: [Lee] Editorial review of no root introspection of Subscription RFC
    • Lee: Not finished, but high on the list because it is required for spec cut. Should be done by next meeting
  • 585: [Everyone] Post examples where default values are used with arguments and input objects
    • [Mike C] added example from Indeed’s GraphQL API
  • 589: [Everyone] Review the @defer/@stream spec edits
  • 590: Discuss options for alternative meeting times
    • Previous Discussion
    • [Benjie] It was discussed that the current meeting time is extremely inconvenient for people in various timezones including Australia, New Zealand and Asia. It was suggested that alternating times or finding a better pattern might make the Spec WG more accessible. It was noted that just changing the time would not be enough, since that would just make the time inconvenient for another set of people.
    • [Andi] I am located in Australia and the current time is 4 am which simply not great. Moving it to 2h ahead it would set the meeting at 6am, which is still not great, but much better. But as noted above: there is no perfect for everybody around the world. 6am in Australia would mean midnight in India for example. I propose to rotate the time to make at least every 3rd or so meeting acceptable for every time zone.
  • 591: [Lee] Research data collection techniques for finding a good time/set of times for Spec WGs
    • Lee: Not finished, but high on the list
  • 592: [Benjie] Open an issue to discuss expansions we might take atop Schema Coordinates
    • Benjie: No updates
  • 593: [Benjie] Investigate explaining what a request error is the first time we mention it
    • Benjie: No updates
  • 261: Spec Cut Date
    • Lee: I will close this issue. This information is out of date. 30-45 days from now seems reasonable.
  • 291: Updating CLAs and copyright notices in GraphQL repos
    • Lee: Will take this as an action item.
    • ACTION - Lee: comb through with Brian to make sure these have all been dealt with.
    • Morris mentioned a missing CLA (dead link) but I missed the refere