Karl Bunyan and have just started a joint venture called fbExchange.net. fbExchange is a Stack Exchange site aimed specifically at Facebook Application Developers. The idea is that the existing system of Facebook's community forums are at best inadequate for the purpose of asking and answering questions, and that Stack Exchange provides a much more efficient Q&A format.

We've pre-populated the site with a handful of questions and answers, but it'll of course be up to the community to ask the questions, and Karl, myself, and a handful of other devs will be there to answer as much as possible until we get enough community to support both ends.

See you there!

I've just finished adding support for the new Facebook Dashboard API to the .NET Facebook API Client project. The functionality is available by downloading the latest changeset from the project's source control. I hope to be providing a beta release of the project in the next month or so.

I recently provided this feedback to Facebook on their Developer Feedback to Facebook forum:

1) Hire a full time community manager. Someone at Facebook recently informed me that there is no full-time community manager, which, well... explains a lot. I don't think there's a whole lot more explanation needed here.

2) Kill all dev support-type forums. Forums are not the appropriate format for asking and answering development and API-related questions. These forums should be replaced with something like Stack Overflow - they offer Stack Exchange, which would allow Facebook to have its own Facebook-branded Stack Overflow site. I've been using Stack Overflow for a while now, and finding answers to my questions is much easier in that format than any forum I've been to.

3) For the API, pick a standard and stick to it. As I've already reported, the new Dashboard API is currently broken from a standards perspective. I understand that it's still in Beta, but breaking your existing standards, even with a Beta feature, is IMHO, unacceptable.

4) Fix your documentation. Your documentation is broken or bad in so many places I can't even start to list them, but here are some of the recurring problems:

• Ensure that the documentation is accurate! This seems like a no-brainer, but I've encountered documentation that was just plain wrong on more occasions that I care to count
• Every function should have a brief one- or two-line description at the top, with more detail later if required
• Either remove the standard arguments in all documentation, or list them in all documentation - don't mix and match
• Group required and optional arguments together - I've noticed that when a new argument is added, it's generally just appended to the end, which can make reading the arguments list frustrating and/or confusing
• Have a list of all acceptable overloads, or create multiple similarly-named methods to support the desired semantics - many methods accept several "correct" combinations of arguments, but they aren't immediately apparent without some digging
• At a minimum, have sample responses for both JSON and XML

• Have sample requests for at least the most commonly used overloads

  5) Timely responses to bug reports, and progress updates if they're being worked on. No further explanation needed here either.

This needs more blog!