[twitter-dev] Re: Comments for the group and Twitter staff

[zippy_monster]

On Sep 16, 1:41 pm, Alex Payne  wrote:

> One thing I have noticed, though, is developers going through our user
> support track (viahttp://help.twitter.com) rather than contacting the
> Platform Team via a...@twitter.com or by filing an issue on our issue
> tracker. Our user support folks try their best, but they're often not
> able to answer developer questions and are likely to hand that issue
> off to our team and close the ticket. Contacting us developer-facing
> folks is a much better way to get your issue answered.

Do developers not use or respond to the support tickets directly?

- alex

[twitter-dev] Re: Comments for the group and Twitter staff

[zippy_monster]

On Sep 16, 10:37 am, Alex Payne  wrote:

> Often times, we don't hear from unhappy developers until they're
> already outraged and posting on their blogs or in this group. Please:
> give us a chance to help you out first. We may not always be able to
> make your particular issues our highest priority, but we'll give it
> our best shot. If you're still pissed, then you can go vent :)

Well take a look at the grumbling about the OAuth stuff.  Mixed in
with complaints about OAuth are complaints about Twitter support being
non-responsive.  Take a look at this from earlier this month:



That person was waiting two months(!) for a response, only to have his
support tickets deleted.  I suspect a lot of the unhappy bloggers have
indeed tried to contact Twitter, and that this group (and the blogs)
are an outlet of last resort.  Understaffed or not, that sucks for the
developers.

[twitter-dev] Re: Comments for the group and Twitter staff

[zippy_monster]

On Sep 15, 11:04 am, Alex Payne  wrote:

> Please understand that the denormalized lists are currently provided
> to developers on a best-effort basis. For the vast majority of Twitter
> applications, this data isn't necessary. A specialized class of
> applications need this data, and we're doing our best to provide it.

As a developer, implementation details are mainly a recreational
interest.  My primary concern is the end result (does it work? or
not?).  Excuses and apologies are nice, but not a substitute for more
explicit testing and communication.  So far I've run into two
disruptive changes:

- Today, for a brief period, API queries were returning twice the
number of responses they should have.  Instead of showing the proper 6
DMs, I was getting 12 back.  Oops.

- Previously, the way POST + OAuth requests were being handled
changed.  The code I was using (MGTwitterEngine + various OAuth hacks)
was sending GET arguments with every request (even POST).  For a while
this worked, but in the past few weeks this broke with no warning.
Yeah, that was sloppy client-side code, but the documentation was
silent on this, and certainly the error message (invalid/re-used
nonce) was not terribly helpful as a proper nonce was being generated
each time.

Additionally, Internet rumblings about how OAuth was handled lend
credence to the idea that the API just isn't terribly stable... both
from the idea that you're pushing people to use what is officially
considered an experimental API, and that it's being treated as an
experimental API (OAuth specific outages for instance).

Or, the current pagination problems.  The threads I see here seem to
all be started by API consumers.  What's missing from the picture is
an announcement from Twitter that some feature is broken.  That smacks
of really poor (well, non-existent) communication.

So, yeah, after spending time tracking down the above problems, and
reading general internet rumblings, my gut feeling is that the Twitter
API simply isn't terribly stable.  Specifically, I wonder how serious
Twitter is about testing things in a non-production environment.  If I
had to propose a solution, it would be to keep a more explicit list
(blog, regular group postings, whatever) of what changes... even if
you think it's insignificant.  When something breaks, no matter how
small, a formal announcement would be great.  If such a thing exists,
I sure don't know about it.

The API blog hasn't been updated since July.  The third hit on Google
for "twitter api" is a post to this group begging for documentation.
The API changelog is out there, but it too seems like it's not
consistently updated.