Skip to content

Latest commit

 

History

History
280 lines (257 loc) · 33.3 KB

2019-06-06.md

File metadata and controls

280 lines (257 loc) · 33.3 KB
Raw

GraphQL Working Group Meeting 2019-06-06

Agenda

Action Items

  • Review DevStats / Lee Byron (@leebyron)
    • @leebyron: Discuss idea to track commenters by company with @caniszczyk (context)
  • Tracking actionable items after each WG / Ivan Goncharov (@IvanGoncharov) / APIs.guru
  • GraphQL.org Q&A & Call for Maintainers / Lee Byron (@leebyron)
    • Unclaimed: Write article explaining initial steps, could write it and @leebyron should review it. Explore ways to find maintainers. (context)
    • @leebyron: Set a vision for what graphql.org should be (context)
    • @leebyron: Open GitHub issue to have general discussion for next steps for graphql.org (context)
    • @leebyron: Open GitHub issue on the graphql.org repository to set up first Working Group meeting. (context)
  • Interface Inheritance / Michael Staib (@michaelstaib) / ChilliCream
  • @oneField directive (input unions) / Benjie Gillam (@benjie)
    • @leebyron: Schedule discussion to touch base on alternatives to input unions. (context)
    • @IvanGoncharov: Invite Vince Foley (@binaryseed / creator of another proposal) and other people to working group (context)
    • @benjie: Work towards a clear definition of the problem this, and other approaches, are addressing. (context)
    • @leebyron: Clarify policy regarding competing RFC drafts and draft expections. (context)
  • GraphQL FAQ / Ivan Goncharov (@IvanGoncharov) / APIs.guru

Notes

Review DevStats / Lee Byron (@leebyron)

https://devstats.graphql.org/

  • Lee: Built by Chris (@caniszczyk) who’s working at the Linux Foundation
  • Lee: Tracks activity statistics on various GraphQL projects
  • Lee: Useful, but not a perfect measure of health for the community currently. There's a lot of potential here.
  • Lee: Shows that the graphql-js repository is the most active
  • Lee: Many projects can be slow-moving, which is fine and healthy
  • Lee: Question: What do people think of the tool?
  • Rikki: It would be cool to track commenters by company
    • Rikki: There is already a top commenters board which touches on that.
    • Lee: Action Item: Will bring this idea up with Chris!
  • Lee: CTA: Bring up other ideas for tracking health overall and for specific projects within the GraphQL organization
  • Erik: IBM Research ran a project mining GitHub for GraphQL schemas
    • Erik: We ran the search twice. Once in Nov 2018 and again in May 2019. Growth between these two points was over 60%. ~3500 vs ~7000 found files.
    • Erik: Search was limited to public repositories which might be a pretty small subset of the total, although the growth rate is still a useful metric.
    • Erik: I'd be happy to share details and statistics
    • Lee: It would would be awesome to track these statistics more regularly
    • Erik: More details on the GraphQL SDL growth on GitHub: https://snag.gy/lMTjRV.jpg
  • Rikki: There 112K GitHub repositories with graphql-js defined as a dependency (from GitHub stats)
  • Rikki: Question of validity (if multiple sources show similar growth, it’s a good sign)
  • Lee: DevStats is a good start. We should keep thinking of other useful metrics to track.

Slack Alternatives / Lee Byron (@leebyron)

  • Lee: I want to open a discussion of how best to create community hubs for the whole GraphQL community. We've been using Slack for the past few years, but have run into a few problems. Are multiple online communities a bad idea? If so, what are some alternatives?
  • Michael: Slack has 10K message limit. Slack is not a great fit for large open-source projects.
  • Lee: We've hit that limit as well. It’s painful. Unfortunately, in discussions with Slack, support for large open-source projects isn’t something they’re interested in improving.
  • James: Apollo has hit this limit as well. A lot of context was lost. Slack is no longer a useful tool for the community and provides no consistent answers.
    • James: We've researched some alternatives: Discourse, Disqus, Spectrum
    • James: We chose to switch to Spectrum. We like the real-time chat and search indexing support. Spectrum has a feature to import members from Slack so the transition was pretty easy. Overall, we've had a positive experience. ZEIT and a lot of the React community is already using Spectrum.
  • Lee: I've heard good things about Spectrum so far. It seems to be working well and has great transition support.
  • Les: Question: What about multiple spaces vs. one central option?
  • Evan: I've had a good experience in the GraphQL slack with multiple channels
  • Michael: Question: With multiple Slack channels, which channel do you turn to if you’re new to the community?
  • Benjie: We already have representation on multiple platforms. We should have one central place but not to the exclusion of others. Some colleagues have refused to use Slack, for example, because it’s not an open-source tool.
  • Ivan: Problem: Templates for GraphQL issues/PRs steer towards StackOverflow currently. We're in need of place for larger discussions. Slack is a good and fast solution for starting a conversation but not for bigger discussions. Spectrum (as a forum derivative) would be a good solution.
  • Lee: I agree. StackOverflow is preferred due to its indexability. It's easy to find a link to a discussion. GitHub comes with a maintenance burden of answering questions.
  • James: GitHub will be adding a new button on repositories. "Go here to ask questions about this project". It'll have an integration with Spectrum communities. Spectrum is now owned by GitHub.
  • Lee: Takeaways: Spectrum is the clear front-runner. It's probably okay to have multiple communities as long as it’s clear which is the primary community and where you can expect people to be.
  • Rikki: Regarding multiple communities, if we’re designating a primary community, it would be good to actively steer people towards participating in that community.

GraphiQL WG Update / Rikki Schulte (@acao)

  • Benjie: We decided to create a GraphiQL Working Group for IDE progress. We've set up the group and created a maintainer team. We've gained access to the repositories. Lee set up an GraphiQL roadmap, outlined in four stages:
    1. House-keeping stage: Merge tooling and make projects similar
    2. Migrate to a monorepo including all of the IDE: GraphiQP, CodeMirror, the language server. All of the parts.
    3. Modernize the stack. By using hooks, for example. We want to be able to more easily split the package up which will make it easier for IDEs to use.
    4. Design improvements
  • Working Group:
    • Benjie: The first meeting was well-attended
    • Benjie: Question: Where should the project go? Which parts? What can people use that’s not the entire package. The next version should have a plugin system. We'd want to implement this while retaining a lean core. Users can extend functionality through a plugin. Preset system, manage pre-packaged lists of plugins, including themes and components. This might be similar in structure to ESLint, which also supports configs/plugins. Many other projects have a similar extension system.
  • Benjie: Many people are using GraphiQL with very large systems. Any plugin system added will need to be performant.
  • Benjie: We're working towards moving everything to the monorepo. The versioning strategy is still up in the air.
  • Rikki: We've moved all components into monorepo, got most things working, prettier still needs to be migrated, git history could be preserved (years of work), when ready to move, PRs and issues will all be moved to the GraphiQL repository using tooling
    • Rikki: This should not require a version bump, mostly formatting changes and module paths, move to TypeScript (only GraphiQL for now) as proof-of-concept is nearly done, transition Flow -> TS, with transition comes a major version bump to prevent breaking downstream work (flow type, etc.)
    • Rikki: There are still open questions that will be added to working group, discussed alternative editor than Codemirror: Monaco (VS Code), many ecosystem-relevant tools like Altair, OneGraph use Codemirror, should multiple modes be supported in the long run? For 1.0 Codemirror will be used, but plugin system could offer third-party editors, language server and other possibilities. Core will stay attached to React & Codemirror
    • Rikki: We're still in early stages planning the plugin system. Open issue for the GraphiQL repository (graphql/graphiql#829)
      • Plugin proposal template: How something would work as a plugin, be it a component or core system
      • React Hooks vs Apollo State
      • We want to leverage the decisions and insights which has already been put into practice, but keep the projcet lean and performant.
      • Waiting on NPM keys. Officially handed off the keys in the first WG meeting. Still waiting on that transition to complete.
  • Rikki: We're still figuring out what we need to do with licenses, especially with a monorepo. CodeMirror itself is BSD licensed as is the GraphQL language service.
  • Lee: Happy to help migrate those to MIT
  • Benjie: Question: Copyright, still Facebook or GraphQL Foundation?
  • Lee: We want to change the copyright along with a version release. All with transition to the GraphQL Foundation.
    • Both license and copyright will coincide with a version release.
    • Keep Lee in the loop regarding license/copyright updates.
    • We might want an NPM machine/bot account to own publishing access.
  • Benjie: Should Contributor license agreement get CLA as well?
  • Lee: Facebook’s CLA will be disabled but a new one should be put in place
  • Rikki: Future section - Working out a flow for transitioning issues/prs. Apply existing PRs on top of the monorepo. We’ll be reaching out to contributors to ensure that they can transition their work to the new repository. Don’t want things to get lost in the shuffle. Once it goes live, hoping to dive in to some more explorations splitting out fault tolerance parser independent from CodeMirror, common grammar with Apollo, GraphQL foundation tooling is useful to other projects out there. Reduce dependencies: GraphQL config.
  • Benji: If anyone else is interested in helping out reach out to one of us.
    • Proof of concept. Check out that if interested, but also let us know if a monorepo shouldn’t be the approach moving forward.
  • Lee: Glad to see hard work on this, will be awesome for GraphiQL project. Question about plugin system: Will architecture be proposed before starting to build?
    • Benji: Will likely involve a whole bunch of POCs. If we can solve all problems with plugins, great, but it’s possible that some problems will be addressed by a plugin system and others addressed by a theme system.
      • Needs to serve not just GraphiQL but any tools built on top of GraphiQL.
      • Hidden fragment auto-completing support (gatsby example)
  • Lee: Another question about moving to Monaco (editor) making sense. Any specific problems with Codemirror that motivate the transition?
    • Rikki: Monaco allows different grammars? Leverage a more interoperable grammar system than CodeMirror.
    • James: Monaco vs CodeMirror - Monaco has built in integration with the language server. Really nice to see work to the language server show up in your tooling.
    • Lee: So it makes more sense to use Monaco to leverage grammar support
    • James: Apollo VSCode extension could be GraphQL VSCode extension, the more platforms support protocol, the better the ecosystem gets
    • Lee: A language server supports a file system?
    • James: Codesandbox for example uses a virtual file system but as GraphQL expands the feature of having multiple files per schema would be great to have. Analogy between GraphiQL as project viewer. Big caveat is that Monaco does not work for mobile devices in any way. Big tradeoff on iPad usage
    • Michael: Is this still true? Microsoft announced support for those devices and Monaco seems to be supported as well. Monaco allows to add features to language server, can layer integrations on top of language protocol making it better
    • James: Apollo project uses core language server and adds integration for commercial platform for features like performance timing, etc.
    • Lee: Sounds like a compelling feature. Relying directly on the CodeMirror API. Swap out CodeMirror implementation with the Monaco implementation. Shouldn’t be a major version bump. High level goal: pull all these efforts together, get the biggest impact.
    • Rikki: Engage stakeholders as early as possible, many people were supportive of Codemirror, built tooling around Codemirror already, might be a big transition. Especially OneGraph is very heavily coupled with Codemirror, binding to DOM, etc. Have to engage and see how feasible switch is, should multiple systems be supported in the future? Maintenance and downstream dependency questions still exist. Sounds like better option though
    • Benji: We have a need for an incremental fault-tolerant parser, which many projects need. Interacting in GraphiQL with the text box, browsers are parsing the input themselves, but if we can share the work inside of GraphiQL, with an intermediate representation, it will help us out and the larger ecosystem.
    • Benji: CTA: Get in touch if you have experience building that kind of thing.
    • Lee: What else do you need? Any additional contributors? Roadblocks? How can working group help?
    • Benjie: Main thing is getting input from people who like to build features on top of GraphiQL. A challenge of building a plugin system is figuring out how to build it. We can’t do this without getting feedback and suggestions from people. What would simplify the task of using it? Help with implementing features would of course be welcome but core components should be figured out first.
    • Lee: Makes sense. Michael, James, I encourage you to get involved since you have experience building this type of thing.
    • James: We have a few team members which are part of the GraphiQL working group.

Tracking actionable items after each WG / Ivan Goncharov (@IvanGoncharov) / APIs.guru

  • Ivan: We had a working group meeting previously. Some of the agenda items were around PRs with spec proposals. Some points were agreed upon and then no action was taken and points were forgotten. For example, a renaming initiative was planned but the initial leader disappeared. People willing to take over with actionable items don’t know that a prior decision was made. Currently, a change in licenses is planned. This factor should be improved.
    • Ivan: Proposal: Try to have actionable items defined, even for the most simple things like license changes. These actions need to be tracked and published including who works on it. The GraphQL Foundation is doing a lot of good stuff for the community, but knowledge about ongoing issues is rare. Many participants are unaware of previous discussions. Even I forget about previous decisions.
    • Ival: Question: What can we do about it?
  • Lee: I like the idea of pulling out actionable items. We take pretty comprehensive notes which are posted for previous meetings, but actions can easily get lost.
  • Lee: Specific to proposals. The proposal needs a champion who is in charge of pushing the proposal forward. One thing we could do is open GitHub issues to track every action. We could tag the stakeholders or add a CTA asking for someone to take an action. I often suggest next actions but there isn’t always someone to own the action.
  • Ivan: We could put actionable items into notes. Maybe somebody wants to collect previous decisions?
  • Devon: As part of the note-taking process, note takers could collect the action items and include them in a separate section in the document.
    • Action Item: Pull out action items from today's meeting notes and add to a separate section in the document (Devon)
  • Lee: I agree. Points and decision often get lost. Good idea. Tracking action items is important. Maybe some items don’t deserve an GitHub issue.
  • Evan: Many meeting formats, as part of the default agenda, include a section to review previous actions items.
    • Action Item: Add meeting agenda item to review previous action items (Bruno)
  • Lee: Great idea. One more thing to keep an eye on is to keep track of people who attend meetings. We don't always have the same attendees in the WG meetings, but even a "No progress" udpate might be useful for previous action items.

GraphQL.org Q&A & Call for Maintainers / Lee Byron (@leebyron)

  • Lee: What do we want to do about this? GraphQL.org is the project with most distributed access rights. It doesn’t look like it needs more maintainers but it does need higher accountability. There are similarities between the GraphQL.org and GraphiQL projects. For GraphiQL, people cared about improving things and this seems to be missing for graphql.org. If anybody feels strongly about creating a similar working group, it would be impactful.
  • Ivan: Great introduction. Somebody passionate should take care of graphql.org. I can give context to many things but there should be a passionate person, maybe front-end developer, for writing documentation. Basically a champion. It would be best.
  • Tanay: I'm interested but would like some guidance towards participating.
  • Craig: Consideration of graphql-js, core project docs, should those be separate sites or projects?
    • Lee: Open question, lines are blurry and discoverability for documentation is an important thing. Coming from a maintenance point of view, it’s a problem that documentation is separate from implementation. Graphql.org should be rather generic and only contain high-level information about GraphQL project.
  • Alec: Feel strongly that graphql.org should be as separate from graphql-js as possible. It already feels like the GraphQL community feels like it’s hard to separate GraphQL at a high-level from JavaScript.
  • Michael: GraphQL.org is more for learning about GraphQL in general
  • Alec: If we need somebody as a champion, I’d be up for it
  • Ivan: Clarify on graphql-js side: I see a maintenance problem. Host it out of the graphql-js repository. The site/docs shouldn’t live in the project repository. About languages, we have a page with docs on other language support. Examples in different servers. Not sure if we have examples in different languages. Reference implementation, but I don’t think it should be the responsibility of the website to list all options.
  • Michael: The code part you referred to seems hardly readable and understandable, should be better structured
  • Ivan: Too specific for this discussion. Similar approach as with GraphiQL, so forming a separate working group should be helpful
    • Action Item: Write article explaining initial steps, could write it and Lee should review it. Explore ways to find maintainers
  • Lee: Multiple overlapping problems. Sense of the whole effort feels abandoned. I like what the GraphiQL WG is doing. We could have a first WG meeting with low commitment or we could have a conversation async. No one is immediately sure what the next thing to do is.
    • Action Item: Set a vision for what graphql.org should be. (Lee)
    • Having some design support would be really useful. Next week, Thursday (2019/06/13), meeting of GraphQL Foundation board where we set a budget. One item for the budget should be design support for graphql.org. Last set of things is taking care of tasks. Listing out what all of those things are, they’re are going to be a ton. Still listed as a Facebook open-source project. Still licensed as BSD. Many little tasks which need to be compiled and mark which are actionable.
    • Lots of work here so totally reasonable that it feels scary.
  • Alec: Can there be a kanban board where we track all of those items? How do I help you get organized?
  • Lee: Good question, we could try using GitHub projects, GraphQL.org repository would be preferable place to open a task/issue for it
    • Action Item: Open GitHub issue to have general discussion for next steps for graphql.org (Lee)
  • Tanay: If you could define the vision, I could take on from there. Even with design it should be possible to get people working on it, the hardest part is conveying the vision. Another idea is moving the site to Gatsby, since it’s easy to pick up work on that. Charting out specifics, creating actionables out of it should be the workflow
  • Lee: If Gatsby were around when we started the site, we would have used it, but we ended up rolling our own thing.
  • Alec: We should talk about a meeting time for this new working group
  • Lee: I'll open an issue on the graphql/graphql.github.io repository to set this up.
    • Action Item: Open an issue on the graphql.org repository to set up first Working Group meeting.
  • Benjie: It was suggested to use Discourse for public comments on graphql.org public page. We should instead redirect to GitHub issues instead of allowing posts on the public page.
  • Lee: I agree. It makes sense to funnel people into existing high-quality tools.

Interface Inheritance / Michael Staib (@michaelstaib) / ChilliCream

  • Michael: As far as I understood, it’s kind of ready to go, it’s about adding the ability for interfaces to implement other interfaces, this would simplify stack implementation
  • Lee: Makes sense. What do we need to do to unblock progress on this. Mike M. was working on this before?
  • Michael: Mike worked on it before
  • Lee: We should ping Mike and ask if he’s still able to work on it or ask another person to be a champion for this
  • Lee: We should make sure to have checked all boxes, getting it into the reference implementation. So far it wasn’t added, let’s make sure there’s a champion for this
  • Michael: Happy to take it on as the champion. We would like it in our implementation. He seemed to last be active on it in April. Will ask him about status.
    • Action Item: Touch base with Mike re: progress on interface inheritance proposal (Michael Staib)
  • Ivan: One concern is validation rules with fragments where there are already existing issues. We should create a prototype to gather feedback for a couple of months to gather feedback, shouldn’t keep it on stage two for now
  • Lee: Getting details right is always difficult. Good to move slow and deliberately.
  • Matt: As an example with validation rules, one piece of the interface proposal would be that we should tighten up validation rules, disallowing arbitrary spreading of interfaces. This effort is a breaking change for existing builds and should be staged.
  • Lee: Would want to avoid breaking changes.
  • Matt: We don’t want a breaking change but rather the option to opt-in for some users. Might be a good first feature to test opt-in functionality
  • Michael: I agree.
  • Lee: We should reach out to Mike M. and see if he has time and energy to continue and offering support.
  • Michael: I will reach out.

@oneField directive (input unions) / Benjie Gillam (@benjie)

  • Benjie: Would like to move to Stage 1. I can be the champion for it. Please move this forward :)
  • Should have the relevant spec changes to it already.
  • Lee: Can you post a proposal link?
  • Benjie: Basically a tagged input union pattern to specify an object with multiple fields, where only one should be supplied.
  • Michael: So it’s basically a tagged union that only accepts one input type
  • Benjie: Exactly
  • Lee: One reason I'm hesitant is that we should make a decision on input unions. I wouldn’t want to have multiple stage one proposals for input unions at the same time.
  • Benjie: oneField might still serves a purpose even if we have input unions, but there’s certainly overlap and can understand the hesitation.
  • Lee: It feels like the example introduced (see PR) could be represented as a real input union, so it really is an input union of three object with one required field
  • Benjie: If you skip down to the example, the proposal allows mixing, so you could have “title” as of type text input and also “sub title” which is of the same type, it’s basically an introspection feature, we don’t currently have a way to expose this to the consumer.
  • Michael: Wouldn’t it be better to find a way to expose directives on types and fields? In schema stitching it would great if you could inspect directives. To introduce special directives, might not scale.
  • Benjie: I’ve exposed this as an @oneField directive, the actual exposure isn’t important, it’s similar to how @deprecated is implemented
  • Lee: Two possible paths:
    1. Adding interesting behavior to the schema
    2. The way that it’s representative in SDL no important, but we would be introducing a new concept. Adds on existing behavior to emulate tagged unions.
  • Benjie: It’s both backwards and forwards-compatible
  • Lee: Next step might be to have a discussion with the people discussing alternatives to input unions. Could be a separate group to discuss or an agenda item for the next meeting.
    • Action Item: Schedule discussion to touch base on alternatives to input unions. (Lee)
  • Matt: One very interesting thing is, the specific proposal is achievable with graphql-js using the directive and some minor changes to the server and validation rules. We might be able to showcase how to use this without modifying the existing spec. Having real-world use cases where people are getting more safety should be an argument towards exposing this as a first-class item.
  • Lee: I think it’s a compelling option and worth exploring. A challenge is whether to make this a directive or a new kind of type, because it does need to be represented through the introspection system as something different.
  • Ivan: Since there are multiple ways on how to achieve this. We should make a decision, since it’s a recurring topic we have discussed often. We previously discussed technical aspects, but in reality we disagree about partial items which is why we haven't made much progress.
    • Action Item: Invite Vince Foley (creator of another proposal) and other people to working group.
  • Lee: Next actions: Benjie to help, to come up with solution agnostic right up to the problem domain, covering use cases people want to enable and query patterns people want to be able to use. Capturing a defined problem will make it easier to measure the potential approaches. Clear agreement on the problem will help us make progress on the solution.
    • Action Item: Work towards a clear definition of the problem this, and other approaches, are addressing.
  • Ivan: Another small issue, RFC acceptance criteria should be refined, what would be the acceptance criteria for this?
  • Lee: Strive for low bar of merging
  • Ivan: I would continue to ask Vince if a document is finished, could I merge it then?
  • Lee: Merging is totally fine since it doesn’t change the state of an RFC. We should have a folder to keep people up to speed
  • Ivan: Can we define as an acceptance criteria: If a creator thinks a proposal is finished, they should be able to merge it
  • Lee: We don’t even need to think about criteria or finished for this document. Those documents are so we can collaborate. Documents should set clear expectations that the document is a work in progress.
  • Ivan: I will contact Vince so I can execute on this. Thanks for clarification
  • Rikki: One more thing, I just wanted to make sure and advocate for Benjie’s proposal of @oneField, maybe we could reframe it as a polymorphic input proposal rather than a specific input union proposal
  • Lee: Let’s keep the RFCs about problems to solve and extend spectrums. Whether to call it an input union or polymorphic inputs can be decided.
  • Benjie: Should we update the criteria for becoming Draft 1, to say that’s not competing or something similar? Difficult to describe what that might sound like.
  • Lee: I think this is a good idea.
  • Benjie: Challenge the idea that we can’t have competing drafts. For ECMA, for example, you could have competing drafts, doesn’t mean that one or both might not make it into the spec. Just means that they’ve passed a certain criteria.
  • Lee: It’s reasonable to push back on this and let's take it offline to talk about this. The main selling points would be
    1. What are the actual expectations of moving from zero to one?
    2. How do we want proposals to be written (problem or solution-focused). Biggest difference between stage 0 and 1 is deciding whether it’s an important point to bring into the spec. In this case, there’s a lot of people striving to implement polymorphic inputs but many different opinions as well
  • Action Item: Clarify policy regarding competing RFC drafts and draft expectations.
  • Benjie: A lot of the concerns are regarding to aesthetics.
  • Lee: Sure, it impacts the query language hugely
  • Matt: Should we have some form of forking in RFC phases?
  • Michael: We need some kind of way of documenting that these RFCs address the same problem.
  • Ivan: Could we agree that the input union topic is a special case currently? I’m worried that we will complicate this too much. Other things currently available are rather simple, most of the times simple proposals don’t need those kinds of discussions. Maybe it deserves to be a special case for now and if we experience this again we might think about solving the situation. As a compromise, if there’s a more generic discussion it could be decided upon, so figuring out the problem before getting too technical. Let this be a special case for now and don’t overcomplicate.
  • Lee: Good feedback. I don’t want to complicate the rules. Ack that it’s a delicate balance. Want to set clear expectations but not make the process a burden. Let’s re-evaluate the system and determine what’s missing. subscriptions is an example of a large-scale problem which changes the process.
  • Benjie: One last thing, there’s a lot of discussions across the graphql-spec repo about input unions, we could give them a GitHub label
  • Lee: Let’s take that as an action item.
    • Action Item: Collect and label all proposals related to input unions

GraphQL FAQ / Ivan Goncharov (@IvanGoncharov) / APIs.guru

  • Ivan: Regarding the graphql.org website, what additional benefit could graphql.org bring to the community? What type of problems can be solved via graphql.org? There are many common questions we can provide answers to. For example, many people ask: why can’t we put special characters in enums? Why can’t enums start with a number? We have many GitHub issues with these questions. Aggregating common questions and answers could be done separate from the graphql.org redesign. We could classify issues in the GitHub repo to add to the FAQ.
    • One idea is to quote questions and answers on the website. We should link to the appropriate comment in the GitHub issue.
    • Someone could go through all closed issues, classify them, add categories, and mark to be added to the FAQ.
  • Lee: How do we make this actionable? Adding to graphql.org makes sense. Content is the first step and the most difficult. Providing links to sources like StackOverflow or GitHub resources should be helpful. Do you have suggestions on where these should live?
  • Ivan: We can manage this separately. This could possibly be accomplished by one person, without needing too much context. We would want to give this person commit access to the appropriate repository. I'm not sure which repository that should be. Maybe the GraphQL Foundation repository? This would be a a good learning opportunity for a contributor.
  • Lee: Sounds great
    • Action Item: Set up a repository with the minimal setup required. (Lee)
  • Tanay: Another point I want to raise is that everything should be in Markdown, right? Related to a Gatsby transition, it would be great to have everything in Markdown already.
  • Lee: Totally agree. Give that action item to me and I’ll try to make it as open as possible.
  • Ivan: If there are other topics, the GraphQL.org Working Group and GraphQL Foundation should be the right forum for further discussion