Doug, can you guys do what Facebook is doing, and release it on a beta server somewhere beforehand so we can test it on our apps before you actually release it to the public? A public staging server of some sort. That will keep these surprises from happening, and we can start working out alerts to have in place when things might break our code that go on that beta server. Best of all, it won't ever affect the end user. Keep the releases on that server, then the releases out to the public on a timed release schedule. It might take a little longer to get out to the public, but you'll have a much happier developer base and in turn a much happier end user by doing so. That would be my number one suggestion. Do you guys do any tracking of Twitter itself for developers complaining about the API? I would also think you could gain some insight from that as well.
@Jesse On Fri, Apr 10, 2009 at 12:04 PM, Doug Williams <[email protected]> wrote: > Twitter's development model is pragmatically agile where features enter the > code base right alongside bug fixes. You can see this in our changelog [1]. > What is not clear from the log is that most of the code is written just days > before. > > April 8th's rapid deprecation of the since parameter/If-Modified-Since > header (and to a lesser extent, the removal of undocumented HTTP POST access > to accounts/verify_credentials) [5] caught a number of developers off guard. > The criticism of this hasty change on the impact to hackers and businesses > alike was both valid and appropriate. The results from last month's survey > [6] lead us to believe that the use of this parameter was minimal and that > it was safe to capture performance gains through the deprecation. In > hindsight, our sample size was statistically insignificant because we made a > mistake. > > It is apparent we need to make a change towards transparency. Openness > demands we give developers a clear line of communication when changes are > made that will break current functionality. While these changes are rare, > they do happen. As a result of this week's conversation, we will give a > minimum of 5 business days notice before we ship code that removes currently > documented functionality. Two notable exceptions are critical security and > performance fixes. > > Five days may seem short notice but it is a compromise from our standard. > There are two major concerns we must consider when shelving code that is > ready for deploy: > 1) We do not write unnecessary code. Code only exists in the deploy > pipeline for a feature or defect fix that is ready to go out the door. We > view deployable code as an asset that should be handling requests as quickly > as possible. > 2) Un-merged code adds complexity. The Twitter code base is constantly > moving. Deploying code requires merging with the master branch which grows > in complexity as an undeployed branch sits idle. > > We currently use the changelog [1], @twitterapi [2], The API Announce List > [3], and the Dev Group [4] to inform developers of changes in hopes that > features will get used, and deprecations will be honored. I'd suggest any > developer with a long-running application to subscribe to the low noise, > only signal, API Announce mailing-list [3] to receive API updates as they > are released. > > Lastly, lets work together. Tell me what you developers need that we are > not currently providing. How can we better manage this communication? Which > method of notifications work best for you? Aside from transparency with API > changes, what else do you want to know? > > 1. http://apiwiki.twitter.com/REST+API+Changelog > 2. http://twitter.com/twitterapi > 3. http://groups.google.com/group/twitter-api-announce?hl=en > 4. http://groups.google.com/group/twitter-development-talk > 5. > http://groups.google.com/group/twitter-api-announce/browse_frm/thread/5822fbfd5ea857c6?hl=en > 6. > http://groups.google.com/group/twitter-api-announce/browse_frm/thread/68f2667f4e9842aa?hl=en# > > Keep the bytes flying, > Doug Williams > Twitter API Support > http://twitter.com/dougw > > > >
