timrogers

9 ms·

31.
by timrogers 2y ago
I think I’d argue that the models are still a limiting factor for these kinds of tools - but there’s still also plenty of competitive space outside of models. The context you gather, the way you gather it and your prompting matters.
32.
by timrogers 2y ago
GitHub employee here This does exist in GitHub Copilot - it’s called content exclusions: https://docs.github.com/en/copilot/managing-github-copilot-i... I’m not sure if Cody has a similar feature, or if there’s an
33.
by timrogers 3y ago
Super helpful article - it’s so great to have a zoomed out view of the space. One question that stands out to me is where evaluation at the application level should be its own category, rather than folded in to bigger groups.
34.
by timrogers 3y ago
I’ve given up on using iCloud Drive, despite having Apple everything, because I find the sync so unreliable and undebuggable. I never had any issues like this with OneDrive or Dropbox.
35.
by timrogers 4y ago
Could you drop me an email at timrogers at github dot com? I'd love to look into this.
36.
by timrogers 4y ago
I definitely feel your pain and, unsurprisingly, it's something we hear very regularly from users. We're working on it.
37.
by timrogers 4y ago
Author here. We plan to publish a blog post in the next few months that explains how we do this under the hood. We have some pretty nice abstractions and tooling to make it as maintainable as possible.
38.
by timrogers 4y ago
Author here. You've hit the nail on the head on why we default to 2022-11-28 - it's all about protecting the hundreds of thousands of of existing GitHub integrations that rely on our current behavior.
39.
by timrogers 4y ago
Author here. I think it's a pretty nice idea to include deprecation information in the response headers as another way to keep API integrators informed - alongside written forms of communication like blog posts, changelog entries and e
40.
by timrogers 4y ago
Author here. We actually use deprecation headers in our GraphQL API.
41.
by timrogers 4y ago
Author here. I think this is an interesting suggestion, and one we'll have a chat about internally. I definitely see the benefit of being able to easily hit the URL from a browser - although I think it's probably only relevant for
42.
by timrogers 4y ago
Author here! Are you thinking fields in a request or fields in a response?
43.
by timrogers 4y ago
Author here! Supporting many API versions in parallel definitely has an overhead from an engineering perspective - but, as the blog post says, we thought it was crucial that we unlock the ability for us to evolve our API whilst still provid
44.
by timrogers 4y ago
Author here! Honestly, we found that media types within the GitHub API had just got pretty confusing as we use them for so many things - "feature previews", response formats, versions ( https://docs.github.com/en&#x
45.
by timrogers 4y ago
Author here. This versioning scheme was just developed within GitHub - so you shouldn't make any assumptions what this means for Microsoft's and LinkedIn's APIs.
46.
by timrogers 4y ago
Author here! At the moment, we allow teams across GitHub to make their own decisions on REST vs. GraphQL. Some teams are investing heavily in GraphQL (e.g. for the new GitHub Projects), whereas others are opting for REST. That said, we do w
47.
by timrogers 4y ago
Author here! Here's the link to that announcement: https://github.blog/changelog/2022-08-18-deprecation-notice-...
48.
by timrogers 4y ago
Author here - you summoned me :) We have some small changes queued up, but nothing huge or earth-shattering. Our focus right now is on improving developer experience and consistency where we have some weirdness in our current API design tha
49.
by timrogers 4y ago
Author here. That's exactly our thinking - we are making the assumption that we won't want to release two versions with breaking changes on the same day. Who knows, maybe we will be proved wrong, but we think it's a safe bet.
50.
by timrogers 4y ago
Author here. We went for dates because they allow you to see, at a glance, roughly how old the version you're using is. We didn't think that semver made sense because, in our versioning system, all new versions are breaking (i.e.
51.
by timrogers 4y ago
Author here. We just wanted to provide a guarantee to reassure users that the introduction of API versioning wasn't going to mean rapid deprecations of versions. We thought that giving a guaranteed minimum lifetime was a reasonable way
52.
by timrogers 4y ago
Author here. You've put it better than I could have put it myself. Thanks!
53.
by timrogers 4y ago
Author here. Unsurprisingly, we did have a lot of internet debate about how the version should be specified (header or path or query param) and we landed on using headers. But, to be completely honest, we didn’t find super strong arguments
54.
by timrogers 4y ago
Author here. We just wanted to be consistent here with other GitHub-specific headers prefixed this way. We could have had different headers with different formats or tried to change the formats of the old headers, but we figured this was th
55.
by timrogers 4y ago
Author here. We consider new endpoints to be non-breaking changes, so they’ll be available in 2022-11-28.
56.
by timrogers 4y ago
Author here! We think that, most likely, we will end up defaulting to the oldest version. We’ll share specific plans on that when we announce our first version deprecation. Just so you know, we don’t intend to deprecate `2022-11-28` in two
57.
by timrogers 4y ago
Author here! We still love our GraphQL API, and REST and GraphQL continue to evolve in parallel. We’re just aware that GraphQL is pretty different, so if we want versioning there, we’ll need to tackle it differently. (On top of that, GraphQ
58.
by timrogers 4y ago
Author here! Thank you so much for flagging this - it’s amazing what can sneak through so many proof reading attempts. We’ll get this fixed.
59.
by timrogers 6y ago
In the short term, our goal is to build the best flight API for new travel businesses by making it way easier to get started and build a great customer experience. We're also in a good position today to help existing travel sellers w
60.
by timrogers 6y ago
This is an awesome post - nice work! It does a fantastic job of laying out clearly the incredible complexity that underpins travel (which totally shocked me when I started in the industry). I'm Tim, and I lead airline partnerships at [

More ›