The problem is not that the API has bugs, the problem is the way Facebook interacts with the developer community. You have a huge problem and it's not something you will fix by writing code.
I don't know what is going on inside FB, but I can tell you what it looks like from the outside: You hired a bunch of junior developers to "fix bugs" in the platform while the Real Engineers go on to make whatever new bug-ridden feature Zuck wants this week. Except that these new developers don't know how the system works and can't even figure out what is or isn't a legitimate bug.
I mis-linked the second bug in the blog post; please examine it again now. Neither bug has been re-opened yet. The 'auth.logout' event still fires on login. This is obviously broken to anyone who has tried to develop a FB app, and yet the FB engineer looks only as far as some internal documentation before dismissing the claim without explanation.
I'm a 3+ year veteran of the Facebook platform. In all this time I cannot say that support improved one bit. Yes, the Graph API is less janky than the REST API, and the documentation is prettier - but in a lot of ways it has gotten worse:
* There is no way for developers to ask for clarification or add their own observations, like there was in the old Wiki docs.
* The old docs at least tried to document error codes and error results. The new docs make no mention of errors whatsoever. And in the mean time you've added three or four different error result formats because even within Facebook nobody knows what an error result should look like.
Sure, you moved "support" over to stackoverflow, which is at least better organized. But the problem was not the software. Today's problem is the same problem you had before: knowledgeable Facebook engineers are not present answering questions. Combined with the sparse and often wrong documentation, this leaves the community playing ridiculous guessing games.
This is a world of difference from the Google APIs I have experienced: Maps and App Engine. In both cases, there are forums where the actual engineers who work on the features hang out and respond to user questions. These people have names and they're not afraid to talk about the design issues involved. If Google+ inherits this attitude towards developer support, we're going to drop Facebook like an abusive spouse.
TL;DR: Answer questions. Respond to inquiries, even if the answer is "I'm not sure yet". Treat documentation as a first-class citizen. And whatever you do, DON'T CLOSE BUGS UNLESS YOU'RE 100% CERTAIN THEY AREN'T BUGS. Nothing pisses off a developer like spending hours isolating a test case only to be ignored or given the F-U of Won't Fix without an explanation.
I don't know what is going on inside FB, but I can tell you what it looks like from the outside: You hired a bunch of junior developers to "fix bugs" in the platform while the Real Engineers go on to make whatever new bug-ridden feature Zuck wants this week. Except that these new developers don't know how the system works and can't even figure out what is or isn't a legitimate bug.
I mis-linked the second bug in the blog post; please examine it again now. Neither bug has been re-opened yet. The 'auth.logout' event still fires on login. This is obviously broken to anyone who has tried to develop a FB app, and yet the FB engineer looks only as far as some internal documentation before dismissing the claim without explanation.
I'm a 3+ year veteran of the Facebook platform. In all this time I cannot say that support improved one bit. Yes, the Graph API is less janky than the REST API, and the documentation is prettier - but in a lot of ways it has gotten worse:
* There is no way for developers to ask for clarification or add their own observations, like there was in the old Wiki docs.
* The old docs at least tried to document error codes and error results. The new docs make no mention of errors whatsoever. And in the mean time you've added three or four different error result formats because even within Facebook nobody knows what an error result should look like.
Sure, you moved "support" over to stackoverflow, which is at least better organized. But the problem was not the software. Today's problem is the same problem you had before: knowledgeable Facebook engineers are not present answering questions. Combined with the sparse and often wrong documentation, this leaves the community playing ridiculous guessing games.
This is a world of difference from the Google APIs I have experienced: Maps and App Engine. In both cases, there are forums where the actual engineers who work on the features hang out and respond to user questions. These people have names and they're not afraid to talk about the design issues involved. If Google+ inherits this attitude towards developer support, we're going to drop Facebook like an abusive spouse.
TL;DR: Answer questions. Respond to inquiries, even if the answer is "I'm not sure yet". Treat documentation as a first-class citizen. And whatever you do, DON'T CLOSE BUGS UNLESS YOU'RE 100% CERTAIN THEY AREN'T BUGS. Nothing pisses off a developer like spending hours isolating a test case only to be ignored or given the F-U of Won't Fix without an explanation.