Acting on your Feedback

By ‎@jasoncosta‎
Wednesday, 5 October 2011

We love hearing from developers about what’s working, what’s not and what more we can do to support ecosystem growth. Over the past twelve weeks we’ve focused on your feedback: We asked developers to share their thoughts through a survey, the platform team did weekly calls with different members of the community, and Jack invited developers to leave comments on our discussion boards. You gave us great ideas and suggestions, and we’re using insights from your feedback to make improvements for the ecosystem as a whole.

Here are the highlights of what you told us, and the changes we’re making as a result of your feedback:

Issue Tracker - You’ve asked for a central place to host and track issues as they come to light, and a better way for us to report when issues have been resolved. Today we announced a new Issue Tracker, which is hosted on dev.twitter.com. Issue Tracker will replace Google Code Tracker, and we’ll be migrating many of the top bugs over to the new Issue Tracker.

Notification Policy on API Changes - Developers want a clear policy about how we deprecate functionality on the APIs. We hear you, and from now on we’ll strive to give you a minimum of 30 days advance notice before sunsetting something. This 30 days is just a start. For bigger changes like the move from Basic Auth to OAuth, we’ll be conscientious of the time required to make such changes, and we’ll continue to listen when the community asks for extensions.

Rate Limits - We regularly get requests for higher rate limits. Rate limits are 350 requests per user (oauth_token) per hour if you’re making authenticated calls and 150 per hour against the calling IP address for unauthenticated calls. We’ve configured rate-limits this way in order to scale usage of the API with the growth of your user-base: as you bring on more Twitter users, you get additional access to the API. Our goal is to support the largest number of applications delivering value to the largest user-base.

Additionally, we make other tools available that can provide an app’s users with a real-time experience, and without having to poll the REST API. We’re committed to push Site Streams out of beta by Q1. Site Streams will allow applications, for users who have authorized the app, to receive real-time updates for events such as mentions, follows, timelines, and more - and you can receive these without having to manage the rate-limits of the REST API.

More Guidance - You told us you’d like to hear more detail about specific opportunities for developers, and which areas Twitter plans to invest in internally. We aim to be as transparent as possible, so you can make informed decisions as you develop applications. Expect to see more frequent updates on this blog, as well as more Developer TeaTime events in cities around the world, where we’ll continue to furnish guidance. We hope to see many of you in London and New York next week.

Authentication - Authentication is always going to be a complex process. We’ve taken steps to make sure developers have thorough documentation and a Twitter team of developer advocates available to answer any questions you may have. We’d like to hold a roundtable discussion at Twitter HQ, on how we can simplify authentication for the Twitter API: what are the common issues people are facing with OAuth 1.0a, what are the best practices others have gleaned from implementing OAuth 2.0, and so on. Stay tuned for more details on this roundtable discussion to be announced here soon.

Thank you again for your feedback - it’s imperative that we continue to collect that feedback, analyze it, and iterate on the platform.