Raffi, one of the things that really stands out for me in what you are saying here is that there are lots of "moving pieces" that the team is trying to "align quickly". The question is, who and what is dictating the schedule? I get the sense that all the recent changes are parts of a bigger picture plan for Twitter, but the reality is that Twitter HQ has not conveyed a real sense of this bigger picture to the developer community - and it certainly hasn't conveyed why these recent changes need to "align quickly". So inevitably the situation at hand seems to be that some serious developer concerns effectively need to be pushed aside in order to meet some internal goals of Twitter that have not been made public. I can understand that as a choice that Twitter management might make. What I think would be unreasonable would be for Twitter to expect the developer community to not push back.
I think it's pretty clear that the "developer advocate" concept needs to be fleshed out more, and i'll try to push for that at Chirp. If anyone else is interested in helping make that discussion productive, lets get started :-) On Apr 5, 8:45 pm, Raffi Krikorian <ra...@twitter.com> wrote: > to clarify (from my personal view), what taylor has provided to the team is > a clear view into what developers want / think / feel -- basically, a pulse > on the developer community. he's doing a fine job. and for these > particular issues, not only has he conveyed the feelings of our community, > but everybody on the team has also heard it personally. i hope we have more > to say about both these topics soon. as you can all imagine, there is a > myriad of moving pieces that we are all trying to get to align quickly -- > there are technical issues, there are the concerns of our developer and user > community, and then, of course, there are the overall objectives of Twitter, > Inc. getting them all to align is, at times, ridiculously difficult. > > > > > > On Mon, Apr 5, 2010 at 5:01 PM, Dewald Pretorius <dpr...@gmail.com> wrote: > > To be fair to Taylor, we may be expecting too much from his role. > > > When reading the job description of a Twitter Developer Advocate , > > the only traditional advocate responsibility listed there is > > "Represent developer needs when planning new API features and > > changes." > > > Now, if Taylor conveyed our objections to the Platform team, then he > > adequately executed that responsibility. I'm sure he did. > > > The rest of the responsibilities all speak in a Twitter to Developer > > direction, i.e., more a Communicator than an Advocate. > > > In particular, in the About This Job section, it says, "it is > > necessary to have an official voice regularly communicating with the > > community," which underlines Communicator instead of Advocate. > > > http://dld.bz/7Z > > > On Apr 4, 9:39 pm, funkatron <funkat...@gmail.com> wrote: > > > Taylor, > > > > I'm about to vent. Sorry about this. > > > > At some point did you plan on addressing any of the numerous > > > complaints raised against making this anything other than opt-in? > > > > Several of us raised this, and you offered no response for 10 days. > > > See <http://groups.google.com/group/twitter-development-talk/ > > > browse_thread/thread/983086ae9935d50c/d4a8e0fbc0fee5c0? > > > lnk=gst&q=popular+search#d4a8e0fbc0fee5c0> > > > > When you *did* post, you didn't actually address any concerns, or say > > > "hey, I spoke with the API team. This is why it's going like this." > > > Like, say, an advocate of 3rd party developers would do. > > > > I'm not doing Twitter any favors; I realize that. I'm just the > > > developer of a tiny, old open source client whose been hacking away on > > > the API since spring of 2007. I'm not a strategic partner, and I don't > > > bring Twitter any value. No VC funding will be coming my way, I'm > > > afraid, and it doesn't make headlines on TechCrunch when I add a new > > > feature (ping.fm? I supported that in 2007). > > > > But what I would like is to be treated with some respect. If you post > > > something, and get significant pushback, I'd expect at *very* least > > > some explanation about why doing it the way you guys want to do it is > > > a great idea. If you are an advocate for 3rd party developers, as I > > > interpreted your title, then doing us the courtesy of not simply > > > ignoring/avoiding the concerns we voice seems like part of your job. > > > > It seems like you're doing a lot of selling of changes to *us*. That's > > > not an advocate -- that's an evangelist. If your role there is an > > > evangelist, then fine. You're doing a good job of ignoring the tougher > > > questions and sticking to company lines. > > > > The point here is that I used to cut the API crew a lot of slack > > > because I thought they at least weren't feeding us a line. I felt they > > > actually were aiming for transparency, but were just overworked. > > > > If this is the way things are gonna go with someone who is, > > > presumably, tasked with being *our* advocate, I think Twitter is > > > losing the thread. Maybe it doesn't matter for you guys financially, > > > and you'll go on and do Very Important Things and lots of people will > > > continue to view Twitter as Game-Changing Technology, but it sure is a > > > bummer for me. > > > > -- > > > Ed Finklerhttp://funkatron.com > > > @funkatron > > > AIM: funka7ron / ICQ: 3922133 / > > > XMPP:funkat...@gmail.com<xmpp%3afunkat...@gmail.com> > > > > On Apr 1, 8:53 pm, Taylor Singletary <taylorsinglet...@twitter.com> > > > wrote: > > > > > Hi Folks, > > > > > As indicated a few weeks ago, we're launching our new *beta* > > enhancements to > > > > search.twitter.com and the Search API today -- it's currently rolling > > out to > > > > our servers. Thank you all for your feedback. > > > > > *Key API Takeaways*: > > > > > - During the current phase, receiving "popular tweets" in your API > > search > > > > results is *OPT-IN*. You will not see the new top results in search > > unless > > > > you specify the *result_typ**e* parameter on your search query string. > > > > > - The result_type parameter takes one of three values: > > > > * *mixed* - receive both "popular tweets" and most recent tweets > > for the > > > > query. This is the equivalent of the future default behavior. > > > > * *popular* - receive only "popular tweets" for the query. > > > > * *recent* - receive only recent results for the query. This is the > > > > equivalent of the behavior you've come to expect until present > > > > > - Each tweet in a search result will now contain a metadata node, > > with a > > > > field called 'result_type' that indicates whether the tweet is > > "popular" or > > > > "recent". In the future, there may be other result_types. The metadata > > node > > > > will eventually contain other fields as well. > > > > > - In addition to result_type, the metadata node may also include a > > > > 'recent_retweets' field indicating the number of retweets the tweet has > > > > received recently, rounded to a reasonable integer. > > > > > - This metadata field will now appear in search results regardless of > > your > > > > OPT-IN status on the popular tweets feature. You don't have to do > > anything > > > > to receive this new metadata along with tweets in search results. In > > JSON, > > > > the metadata field is simply "metadata." In XML, you'll see it > > expressed as > > > > "<twitter:metadata>". > > > > > *Continued Discussion*: > > > > > To date, Twitter's real-time search has proven to be incredibly > > valuable. > > > > People, businesses and organizations have come to depend on finding out > > > > what's being discussed about a particular topic *right now*. > > > > > We've been really impressed at the integrations many of you have > > developed > > > > using the Search API. Whether it's offering search columns in a Twitter > > > > client, mapping #hashtags to search, or deep analysis of trends and > > brand > > > > monitoring, you've shown us what's possible with Twitter search. > > > > > With this new project, we want to make real-time search even more > > valuable > > > > by surfacing the best tweets about a particular topic, by considering > > > > recency, but also the interactions on a tweet. This means analyzing the > > > > author's profile, as well as the number times the tweet has been > > retweeted, > > > > favorited, replied, and more. It's an evolving algorithm that we'll be > > > > iterating on & tuning until practically the end of time. > > > > > With this initial release, if we detect that there are particularly > > > > interesting & relevant tweets for a given query, we'll display at most > > 3 of > > > > these tweets at the top of the page. We'll also display the number of > > times > > > > these tweets have been recently retweeted as well. > > > > > You can check outhttp://search.twitter.comtoseeour new beta relevancy > > > > results now. Using the new features of the API we're launching today, > > you > > > > could build a similar interface for the popular results but we're > > expecting > > > > awesome & creative uses of these new result types, not necessarily > > limited > > > > to user-facing features. > > > > > Explore the new result formats and options in the updated Search API > > > > documentation: > >http://apiwiki.twitter.com/Twitter-Search-API-Method%3A-searchandour > > > > original post on the subject: > >http://groups.google.com/group/twitter-api-announce/browse_thread/thr... > > > > > Happy Hacking! > > > > > Taylor Singletary > > > > Developer Advocate, Twitterhttp://twitter.com/episod-Hide quoted text > > - > > > > - Show quoted text - > > > -- > > To unsubscribe, reply using "remove me" as the subject. > > -- > Raffi Krikorian > Twitter Platform Teamhttp://twitter.com/raffi