Opt-in beta of "Popular Tweets" for the Search API now available

[Taylor Singletary]

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_type 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 out http://search.twitter.com to see our 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-search and our original post on the subject: http://groups.google.com/group/twitter-api-announce/browse_thread/thread/983086ae9935d50c

Happy Hacking!

Taylor Singletary
Developer Advocate, Twitter
http://twitter.com/episod

[@dbbradle]

Thanks, Taylor and Twitter API team! I know what I'm doing this
weekend :)

On Apr 1, 5: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.comto see our 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-searchand our
> original post on the subject:http://groups.google.com/group/twitter-api-announce/browse_thread/thr...

[Nigel Legg]

Taylor, I have two questions; I thought you answered them in the original thread, but could not find them.
1.  How are "popular" tweets defined? Tweets from accounts with lots of followers, or tweets that have been retweeted the most, or what?
2. And that leads to : you mention having a metadata point for number of times the tweet has been retweeted. Is that as in hitting the "Retweet" button only, or will copying and pasting, editing and adding value also count? If I retweet you, and 3 of my followers retweet that, with the retweet button I get no credit and don't even know it has happened unless I go into the website.  Having a retweets field which only counts the RT button will further entrench this feature which is very damaging to the sense of community and way a lot of people use twitter (certainly over here).
Sorry for the rant.
Nigel.

--
To unsubscribe, reply using "remove me" as the subject.

[Raffi Krikorian]

Taylor, I have two questions; I thought you answered them in the original thread, but could not find them.
1.  How are "popular" tweets defined? Tweets from accounts with lots of followers, or tweets that have been retweeted the most, or what?

from taylor's e-mail:

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.

hope that helps. 

 

2. And that leads to : you mention having a metadata point for number of times the tweet has been retweeted. Is that as in hitting the "Retweet" button only, or will copying and pasting, editing and adding value also count? If I retweet you, and 3 of my followers retweet that, with the retweet button I get no credit and don't even know it has happened unless I go into the website.  Having a retweets field which only counts the RT button will further entrench this feature which is very damaging to the sense of community and way a lot of people use twitter (certainly over here).

i'm pretty sure its native RTs only, right now.

 

--
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

[Nigel Legg]

Thanks Raffi, I won't go near those retweet functions.
As for the popularity stuff, will the algorithm you use be open?  It wouldn't be good for either side if someone else developed a popularity index which showed different results from yours.

[Raffi Krikorian]

i don't see any reason we wouldn't necessarily publicise it, but, honestly, at this point, i think we're changing it daily.

[M. Edward (Ed) Borasky]

On 04/02/2010 10:05 AM, Nigel Legg wrote:
> > Thanks Raffi, I won't go near those retweet functions.
> > As for the popularity stuff, will the algorithm you use be open? It
> > wouldn't be good for either side if someone else developed a popularity
> > index which showed different results from yours.

As long as the API is open and the social media ecosystem is a
competitive landscape, there *will* be people developing both open and
"closed" popularity and other tweet and tweeter ranking scores. And
they'll all give different but similar scores / rankings. And there
will
be spammers trying to game them, whether they are open or closed. So -
make friends with an IP attorney and get your provisional-patent-
application-writing software ready. ;-)

[funkatron]

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 Finkler
http://funkatron.com
@funkatron
AIM: funka7ron / ICQ: 3922133 / XMPP:funk...@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.comto see our 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-searchand our
> original post on the subject:http://groups.google.com/group/twitter-api-announce/browse_thread/thr...

[Cameron Kaiser]

> At some point did you plan on addressing any of the numerous
> complaints raised against making this anything other than opt-in?

I'm asking the same question, especially after I found

http://apiwiki.twitter.com/Twitter-Search-API-Method%3A-search

listing the default change as a fait accompli. Since it was modified 2 days
ago, I can only assume the requests were either ignored or declined.

Like Ed, I've tried to be patient about this in the past, but this is
unnecessary chaos and (among other things) reflects badly on the API team.

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- "I'd love to go out with you, but I'm taking punk totem pole carving." -----

[Dewald Pretorius]

+1 ^ 10. Very well said, Ed. You're getting an enthusiastic standing
ovation and one-man Mexican wave from me.

> Ed Finklerhttp://funkatron.com
> @funkatron
> AIM: funka7ron / ICQ: 3922133 / XMPP:funkat...@gmail.com

> > You can check outhttp://search.twitter.comtosee our 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 -

[Dewald Pretorius]

To be fair to Taylor, we may be expecting too much from his role.

When reading the job description of a Twitter Developer Advocate [1],
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.

[1] http://dld.bz/7Z

On Apr 4, 9:39 pm, funkatron <funkat...@gmail.com> wrote:

> Ed Finklerhttp://funkatron.com
> @funkatron
> AIM: funka7ron / ICQ: 3922133 / XMPP:funkat...@gmail.com

> > You can check outhttp://search.twitter.comtosee our 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

[M. Edward (Ed) Borasky]

On 04/05/2010 09:47 AM, Dewald Pretorius wrote:
> +1 ^ 10. Very well said, Ed. You're getting an enthusiastic standing
> ovation and one-man Mexican wave from me.

I think as a community, we're letting a golden opportunity for
discussion about Twitter Search pass us by while we "vent" and "rant"
about the inconveniences and about "roles" and "titles". I'm not by any
means an expert on search in the large, although I do spend a fair
amount of time trying to keep up with the natural language processing
and computational linear algebra technologies that power search.

But I think the discussion we *should* be having is not about the
mechanics of the API, the logistics of API versioning, "developer best
practices" or roles withing the community. I don't even think it should
be about business models, although that's certain a part of it. I think
the discussion we should be having is about Twitter Search itself - how
it should work to meet the needs of the two classes of users I call
"seekers" and "sellers". I posted a call for this discussion on my blog
a while back, but haven't had many takers. So here it is again:

http://borasky-research.net/2010/03/19/seeker-or-seller-what-do-you-think-about-adding-popularity-to-twitter-search-tweetsearchpop/

If there's enough interest, maybe we can put together an "unconference"
session on this at Chirp.

--
M. Edward (Ed) Borasky
borasky-research.net/m-edward-ed-borasky

"A mathematician is a device for turning coffee into theorems." ~ Paul Erdős

[Raffi Krikorian]

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.

--

To unsubscribe, reply using "remove me" as the subject.

[Dewald Pretorius]

Ed,

Yes, we should talk abour Search. But, I disagree when you say we
should not talk about the other stuff.

It is very frustrating when developers essentially stand up as one man
and tell Twitter, "bad idea, don't do it." And they go ahead and do it
anyway.

You know, it's not like we are their primary customers and consumers
of the API. It would be extremely alarming and troubling if they
ignored those guys.

On Apr 5, 9:08 pm, "M. Edward (Ed) Borasky" <zn...@comcast.net> wrote:
> On 04/05/2010 09:47 AM, Dewald Pretorius wrote:
>
> > +1 ^ 10. Very well said, Ed. You're getting an enthusiastic standing
> > ovation and one-man Mexican wave from me.
>
> I think as a community, we're letting a golden opportunity for
> discussion about Twitter Search pass us by while we "vent" and "rant"
> about the inconveniences and about "roles" and "titles". I'm not by any
> means an expert on search in the large, although I do spend a fair
> amount of time trying to keep up with the natural language processing
> and computational linear algebra technologies that power search.
>
> But I think the discussion we *should* be having is not about the
> mechanics of the API, the logistics of API versioning, "developer best
> practices" or roles withing the community. I don't even think it should
> be about business models, although that's certain a part of it. I think
> the discussion we should be having is about Twitter Search itself - how
> it should work to meet the needs of the two classes of users I call
> "seekers" and "sellers". I posted a call for this discussion on my blog
> a while back, but haven't had many takers. So here it is again:
>

> http://borasky-research.net/2010/03/19/seeker-or-seller-what-do-you-t...

[M. Edward (Ed) Borasky]

On Apr 5, 6:01 pm, Dewald Pretorius <dpr...@gmail.com> wrote:
> Ed,
>
> Yes, we should talk abour Search. But, I disagree when you say we
> should not talk about the other stuff.
>
> It is very frustrating when developers essentially stand up as one man
> and tell Twitter, "bad idea, don't do it." And they go ahead and do it
> anyway.
>
> You know, it's not like we are their primary customers and consumers
> of the API. It would be extremely alarming and troubling if they
> ignored those guys.

Well, I don't think that the hundreds / thousands of developers "stood
up as one man". There wasn't a poll, and there wasn't anything except
"truth by loudness" or "truth by repetition". Yes, I personally think
major API changes add unnecessary work to a developer's schedule, but
I don't think that's as big a problem for Twitter and the developer
community as not having a search that meets the needs of seekers and
sellers.

And I'm not terribly convinced that either the old or new Twitter
Search *does* meet the needs of seekers or sellers, because

a. Twitter Search isn't the focus of my own use cases, so I wouldn't
personally know if it was broken, and

b. The blogosphere seems more interested in juicy gossip, the iPad,
Facebook privacy, Google vs. China, lawsuits in the mobile space,
Foursquare vs. Gowalla, etc. If Twitter comes up at all, it's in
reference to Twitter's business model or speculation on growth rates.
Twitter Search seems to be low on their list of things to think / talk
about.

But yes, we should talk about the other stuff. It *is* an
inconvenience, and even in "agile" / "scrum" shops there are strict
rules about change control and change management. That shouldn't be
even a discussion topic - it should be something that's in-bred in
people who've been working with code for more than six months. We
"should" talk about it, but at the same time, we shouldn't *have* to
talk about it. ;-)

[Cameron Kaiser]

> 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.

I appreciate all of that, but the particular issue at hand is only
emblematic of what I worry is a greater problem. If nothing else, a message
to the list simply saying "we're aware you guys don't like it, but we're
doing it anyway and here is why" would have at least won style points and
would have reinforced that you're listening. It's your basketball court, so
of course you get to decide how the game is played, but it would be nice to
tell the players. (Well, okay, that metaphor gets overused during March
Madness.) Seriously, there wasn't a single response back about that from
anyone on the API team, and it wasn't for lack of asking. No one would have
liked it, but acknowledgment of concerns even without being able to act on
them goes a long way.

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com

-- It's lonely at the top, but the food is better. ----------------------------

[Orian Marx (@orian)]

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 :-)

> > > AIM: funka7ron / ICQ: 3922133 / XMPP:funkat...@gmail.com<XMPP%3Afunkat...@gmail.com>

> > > > 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

[Raffi Krikorian]

consider this an acknowledgement and a response, then :P  

these are two pretty big issues (tweet IDs and popular tweets in search).   and the silence has been because we're working really hard behind the scenes to make sure we, ourselves, have weighed all the options on the axes i laid out, and we feel, given that, that we got it right.  we heard all the concerns and we know that change, especially sizable change, can be painful for all.  once we have things finalized, we will definitely be messaging it to the list.

--
To unsubscribe, reply using "remove me" as the subject.

[Cameron Kaiser]

> consider this an acknowledgement and a response, then :P
>
> these are two pretty big issues (tweet IDs and popular tweets in search).
> and the silence has been because we're working really hard behind the scenes
> to make sure we, ourselves, have weighed all the options on the axes i laid
> out, and we feel, given that, that we got it right. we heard all the
> concerns and we know that change, especially sizable change, can be painful
> for all. once we have things finalized, we will definitely be messaging it
> to the list.

I appreciate the response and thanks.

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com

-- You can't carve out success without cutting remarks. -----------------------

[Raffi Krikorian]

we have the developer advocate we want, but, of course, please feel free to reach out to taylor with your concerns and what you would like him to do to help you all out.  i'm sure he would welcome the help.

as for what's going on behind the scenes, i'll describe it out as so:

• tweet ID generation - this is a pure scalability problem that lays at the heart of twitter being able to grow.  unless i'm mistaken, in the end, a centralized way of generating tweet IDs that are strictly increasing by one does not scale.  the method that we generate tweet IDs, and therefore the IDs themselves, will, almost probably, have to change.
• popular tweets in search - twitter is increasingly being relied upon to be the place for relevant real-time information.  most end-users would say that a time indexed search stream is not as valuable.  as you all can probably tell, keeping a real time search index operational is hard enough, but imagine keeping a service running that is simultaneously delivering relevant results along with time indexed results.  that's significantly harder.

those are the issues facing us.  as i said, please bear with us -- once we have weighed all these issues internally, we will of course, let everybody know.  we've heard the concerns, but, if there are new ones, please let us know!

[zn...@comcast.net]

----- "Raffi Krikorian" <ra...@twitter.com> wrote:

> • popular tweets in search - twitter is increasingly being relied

> upon to be the place for relevant real-time information. most
> end-users would say that a time indexed search stream is not as
> valuable. as you all can probably tell, keeping a real time search
> index operational is hard enough, but imagine keeping a service
> running that is simultaneously delivering relevant results along with
> time indexed results. that's significantly harder.

Ah, see, *this* is the conversation *I* want! ;-) For example, search marketing is a well-established branch of online marketing, and both Google and Microsoft provide tools for marketers that tell them what people search for. Microsoft even provides tools that do a half-way decent job of distinguishing between people who are "just looking" and people who are searching with "commercial intention". They also measure this internally and use it to tweak their indexing algorithms so they balance the needs of the seekers and the sellers. Maybe it's on Twitter's road map to provide "Twitter Search Keyword Tools", and then again, maybe it isn't. Maybe Twitter doesn't want to be a search marketing platform. ;-)

All I'm saying is that it isn't just a technical problem - if your data say that Twitter Search users - seekers, since there don't appear to be provisions for sellers yet - that popularity is how they want to rank tweets, and by extension, tweeters, for relevance, then that's what you should go with. Because the third-party monitoring outfits have migrated or will migrate to Streaming and will do the indexing their clients require. And they'll pay Twitter for the access levels they need to meet their clients' requirements.

And if you don't *have* data, well ... ;-)

[Dewald Pretorius]

Raffi,

Tweet id is a no-brainer. We understand that an linear incrementing
number does not scale because at some point it must cycle back to 1.

Search is a different animal.

When I do a Twitter search, I expect your system to tell me what is
*happening* right now. I am NOT expecting your system to tell me what
is *popular* right now.

This popular tweet thing is diluting and violating your entire mission
of "real-time".

If I search for "earthquake" I want to see what is *happening* in real-
time. I have no interest in seeing a 30-minute old tweet from @aplusk
or @ev just because they are trusted accounts and the tweet is being
retweeted a lot (to simplify the popularity algorithm).

If people have a need to see popular tweets, you know what? That is an
ideal service to be provided by a third-party developer/service.

Twitter is real-time, and has defined real-time information. Stick to
it. Don't dilute your mission.

On Apr 6, 1:03 am, Raffi Krikorian <ra...@twitter.com> wrote:
> we have the developer advocate we want, but, of course, please feel free to
> reach out to taylor with your concerns and what you would like him to do to
> help you all out.  i'm sure he would welcome the help.
>
> as for what's going on behind the scenes, i'll describe it out as so:
>

>    - tweet ID generation - this is a pure scalability problem that lays at

>    the heart of twitter being able to grow.  unless i'm mistaken, in the end, a
>    centralized way of generating tweet IDs that are strictly increasing by one
>    does not scale.  the method that we generate tweet IDs, and therefore the
>    IDs themselves, will, almost probably, have to change.

>    - popular tweets in search - twitter is increasingly being relied upon to

> > <XMPP%3Afunkat...@gmail.com <XMPP%253Afunkat...@gmail.com>>

> ...
>
> read more »- Hide quoted text -

[Raffi Krikorian]

hi dewald.

we obviously feel that users want the most relevant tweets first (the
use of "popular" is unfortunate here). and the web interface of search.twitter.com
has begun an evolution in that direction.

it's still unclear what Twitter is going to do with the API (hence the
silence), however, to go with your argument: "time indexed" search is,
potentially, something a third party service could do. we do provide
the streaming API to get much-better-than-search-real-time results.

[Dewald Pretorius]

Raffi,

"We obviously feel that users want the most relevant tweets first."
Has this been determined and confirmed with user focus groups, or is
this just an opinion that originated somewhere in a Twitter office or
meeting room?

I am one of those users, and I have just told you that I have no
interest in seeing old tweets, regardless of how "popular" or
"relevant" they deem to be by your algorithms. When I search Twitter
(and I'm making this statement as a user of search.twitter.com, not as
an API consumer) I want to see in real-time what is happening right
now. That is why I am using search.twitter.com and not google.com for
that purpose. If you're going to rather show "relevant" tweets, then I
will instead use Google because their matching algorithms are far more
advanced and mature.

[Dean Collins]

But raffi why do you have to break the old to offer the new?

Basically I've just updated MyPostButler to work again after your last
unannounced changed the Thursday evening before a holiday break only to
open my email this morning and see you are going to modify search api
yet again in some undetermined period of time.

I understand things need to change from time to time BUT why so often?
Why cant you make the new changes opt-in rather than breaking all the
previous applications already deployed out there.

Regards,

Dean Collins
Cognation Inc
de...@cognation.net
+1-212-203-4357 New York
+61-2-9016-5642 (Sydney in-dial).
+44-20-3129-6001 (London in-dial).

[Dean Collins]

I think twitter forget that API developers are there customers as well, not end users.

At the end of the day if this make my app unviable then you'll lose this development community as a developer and pretty improbable to ever get us back.

I've never funded another application on the Adobe FMS platform after they dropped the 10 seat license and killed the business I funded 7 months of development on..... they are dead to me - should I really be adding Twitter to that list?.... anyone here still developing apps for Friendster? Yes Twitter it can happen that fast.

Regards,

Dean Collins
Cognation Inc
de...@cognation.net
+1-212-203-4357 New York
+61-2-9016-5642 (Sydney in-dial).
+44-20-3129-6001 (London in-dial).

> -----Original Message-----
> From: twitter-deve...@googlegroups.com [mailto:twitter-development-
> ta...@googlegroups.com] On Behalf Of Dewald Pretorius
> Sent: Tuesday, 6 April 2010 9:12 AM
> To: Twitter Development Talk
> Subject: [twitter-dev] Re: What Exactly is a "Developer Advocate?" (was Re: Opt-in
> beta of "Popular Tweets" for the Search API now available)
>

[Nigel Legg]

Raffi, how do you decide what the most relevant tweets are? If you're searching for "earthquake" it's probably because you are concened about someone or somewhere that has been struck by an earthquake, and therefore want to get the most up to the minute information. Just because something has been retweeted hundreds of times and came from someone with a million followers doesn't make it relevant to my search. I use the Qt framework. Try doing a search for #Qt - a fraction of the results are relevant, but I'll cope. If the top places were always filled with quotes or "Spending #Qt with my cutie", it would be lass meaningful to me.  The more I see of the use of "popular" in search results, the less I like the look of it going forward.

[Nigel Legg]

Dewald - agreed and seconded.

[Allan Hoving]

Doesn't this always happen? Paths diverge (usually around money but sometimes around principle) and then it gives rise to something new?

Allan Hoving

http://www.thefrequency.tv

[Nigel Legg]

Ed, I would like to re-read your blog post, but it's redirecting me through oAuth into Twitoaster??? 

[Dewald Pretorius]

Dean,

<sarcasm>
<lines>
<line rel="me">Some developers have too much time on their hands.</
line>
<line>So, Twitter make these changes to give them something to do so
that they can STFU on these forums, because they are too busy chasing
the latest API mod.</line>
</lines>
</sarcasm>

On Apr 6, 10:14 am, "Dean Collins" <D...@cognation.net> wrote:
> But raffi why do you have to break the old to offer the new?
>
> Basically I've just updated MyPostButler to work again after your last
> unannounced changed the Thursday evening before a holiday break only to
> open my email this morning and see you are going to modify search api
> yet again in some undetermined period of time.
>
> I understand things need to change from time to time BUT why so often?
> Why cant you make the new changes opt-in rather than breaking all the
> previous applications already deployed out there.
>
> Regards,
>
> Dean Collins
> Cognation Inc

> d...@cognation.net

[Dean Collins]

Ha ha, love it.

I feel sorry for other developers, for me personally I can walk away from my app at anytime as I see fit because I'm not "reliant" on any single project.

lol MyPostButler (or MyTwitterButler as it was known back then) was given away for the first few months - It was just a byproduct for www.LiveBaseballChat.com - it was only when I was flooded for licenses I decided to charge for it.

I guess I'm also at a disadvantage as I don't personally code anything and just pay other people to build apps for me so 'any' change is a pita on an roi basis.

Regards,

Dean Collins
Cognation Inc
de...@cognation.net

+1-212-203-4357 New York
+61-2-9016-5642 (Sydney in-dial).
+44-20-3129-6001 (London in-dial).

> -----Original Message-----
> From: twitter-deve...@googlegroups.com [mailto:twitter-development-

> ta...@googlegroups.com] On Behalf Of Dewald Pretorius
> Sent: Tuesday, 6 April 2010 9:42 AM
> To: Twitter Development Talk

> Subject: [twitter-dev] Re: What Exactly is a "Developer Advocate?" (was Re: Opt-in
> beta of "Popular Tweets" for the Search API now available)
>

[zn...@comcast.net]

----- "Raffi Krikorian" <ra...@twitter.com> wrote:

> hi dewald.
>
> we obviously feel that users want the most relevant tweets first (the
> use of "popular" is unfortunate here). and the web interface of
> search.twitter.com has begun an evolution in that direction.
>
> it's still unclear what Twitter is going to do with the API (hence the
> silence), however, to go with your argument: "time indexed" search is,
> potentially, something a third party service could do. we do provide
> the streaming API to get much-better-than-search-real-time results.

Yes, and the real-time work I'm doing I do with Streaming. Building your own "time indexed search" on top of Streaming, however, has an *extensive* investment requirement on the part of said third-party services. You've got Firehose-scale bandwidth requirements, Cassandra-scale persistence requirements, and Hadoop-scale algorithmic requirements just for openers.

It's an *extremely* competitive marketplace. Hell, there are profitable businesses out there *giving away* Twitter-based services. You've got to be compelling, cheap, correct, pretty and fast out of the box to compete with them. You can't "make it work, then make it pretty, go sell it and then make it scale" any more. Using Streaming in its current state means duplicating large chunks of Twitter's infrastructure. That's inefficient, and off the top of my head, I can't think of a *single* example of an inefficient business that survived in the long run.

--
M. Edward (Ed) Borasky

borasky-research.net @znmeb

[zn...@comcast.net]

----- "Dewald Pretorius" <dpr...@gmail.com> wrote:

> Raffi,
>
> Tweet id is a no-brainer. We understand that an linear incrementing
> number does not scale because at some point it must cycle back to 1.
>
> Search is a different animal.
>
> When I do a Twitter search, I expect your system to tell me what is
> *happening* right now. I am NOT expecting your system to tell me what
> is *popular* right now.
>
> This popular tweet thing is diluting and violating your entire
> mission
> of "real-time".
>
> If I search for "earthquake" I want to see what is *happening* in
> real-
> time. I have no interest in seeing a 30-minute old tweet from @aplusk
> or @ev just because they are trusted accounts and the tweet is being
> retweeted a lot (to simplify the popularity algorithm).
>
> If people have a need to see popular tweets, you know what? That is
> an
> ideal service to be provided by a third-party developer/service.
>
> Twitter is real-time, and has defined real-time information. Stick to
> it. Don't dilute your mission.

+1000

And can we fix Trending Topics too? Give me the Top 100 or Top 200 or even Top 1000 and let me filter out Tiger Woods, Justin Bieber, Lady Gaga and the iPad! ;-)

--
M. Edward (Ed) Borasky

http://borasky-research.net/smart-at-znmeb

[zn...@comcast.net]

----- "Nigel Legg" <nigel...@gmail.com> wrote:

> Ed, I would like to re-read your blog post, but it's redirecting me
> through oAuth into Twitoaster???

It is? On my web page? Sounds like a bug in the Twitoaster WordPress plugin. There's a Twitoaster widget there, but you should be able to read the blog post directly from the link, and comment with Intense Debate (yet another WordPress plugin - I'm rump-deep in them.) ;-)

Try a bit.ly link - maybe it will work better: http://meb.tw/bY0SI8

--
M. Edward (Ed) Borasky

borasky-research.net @znmeb

[Marcel Molina]

If you have no interest in seeing "old tweets" then pass the parameter that indicates that you want to strictly see the most recent tweets (the legacy behavior). You get what you want and those who are interested in more signal amongst the ever increasing noise can find out the moderately-less-recent-but-most-popular results associated with their search term. You represent one desired use case. There are others. We are providing a mechanism to get one,  the other or both. Choose whichever you like.

--
To unsubscribe, reply using "remove me" as the subject.

--
Marcel Molina
Twitter Platform Team
http://twitter.com/noradio

[Dewald Pretorius]

Marcel,

How do I do that as an end user of search.twitter.com?

I know it's confusing, because I switched from talking about this
issue as a developer to talking about this issue as an end user. I
thought I made that clear when I said, "and I'm making this statement
as a user of search.twitter.com, not as an API consumer."

I have no interest in seeing old tweets when I do a search at
http://search.twitter.com. I expect those search results to show me
what is being said right now (i.e., real-time) about my search phrase.

Yes, I know one can switch views with the API, but I wasn't talking
about the API.

[Dewald Pretorius]

Oh, and one more thing.

In real-time, anything minutes ago or older is an "old tweet" if there
are newer tweets available.

On Apr 6, 12:44 pm, Marcel Molina <mar...@twitter.com> wrote:

[Raffi Krikorian]

hi dean.

I think twitter forget that API developers are there customers as well, not end users.

100%.  for the platform team - you all are our primary customers.  most certainly. 

  

[Raffi Krikorian]

But raffi why do you have to break the old to offer the new?

we do our absolute best not to do so.  as i mentioned in some previous thread - we do reserve the right to add things to the XML / JSON / etc. outputs -- so, please make sure to have parsers that can handle that.  for me, that doesn't break our definition of "backwards compatibility".  

Basically I've just updated MyPostButler to work again after your last
unannounced changed the Thursday evening before a holiday break only to
open my email this morning and see you are going to modify search api
yet again in some undetermined period of time.

as a FYI, we now have a policy here on the engineering team at twitter to not deploy any code on fridays (and long weekends and the like) - hopefully this won't happen to you again.  but, of course, as with any change, there is a chance for a regression.  we do our best to try to make sure that things don't break, and we try to react quickly when they do.  please remember that twitter is a constantly evolving platform.

 

I understand things need to change from time to time BUT why so often?
Why cant you make the new changes opt-in rather than breaking all the
previous applications already deployed out there.

again - its an evolving platform.  we do our best to make things backwards compatible.   i'm happy to provide hints on how to make sure your code can be resilient to forward changes if you want me to.

[Raffi Krikorian]

our search and relevancy algorithms are constantly changing.  we take in a slew of signals like "engagement" or "conversation" around tweets, and use that to pull it higher in search results.  whether we will provide the exact details of how that algorithm works, i'm not sure.  its analogous to google page rankings -- the general notion is well known, but the exact details are constantly changing behind the scenes.

we're still trying to figure out things internally regarding these "top tweets" / "popular tweets" / "relevant tweets", but, as always, one could just connect to the streaming API and get "true real time" tweets for "earthquake".

[Raffi Krikorian]

"We obviously feel that users want the most relevant tweets first."
Has this been determined and confirmed with user focus groups, or is
this just an opinion that originated somewhere in a Twitter office or
meeting room?

twitter does run user studies.  yes.

 

I am one of those users, and I have just told you that I have no
interest in seeing old tweets, regardless of how "popular" or
"relevant" they deem to be by your algorithms. When I search Twitter
(and I'm making this statement as a user of search.twitter.com, not as
an API consumer) I want to see in real-time what is happening right
now. That is why I am using search.twitter.com and not google.com for
that purpose. If you're going to rather show "relevant" tweets, then I
will instead use Google because their matching algorithms are far more
advanced and mature.

as i'm sure you can appreciate, twitter has a lot of users / customers....  you are of course, more than welcome to use google as a search engine for tweets ... :P

all in all - i hope a lot of you are coming to chirp, as i would absolutely happy to have this conversation in person over some beers :P

 

[Nigel Legg]

On 6 April 2010 17:27, Raffi Krikorian <ra...@twitter.com> wrote:

our search and relevancy algorithms are constantly changing.  we take in a slew of signals like "engagement" or "conversation" around tweets, and use that to pull it higher in search results.  whether we will provide the exact details of how that algorithm works, i'm not sure.  its analogous to google page rankings -- the general notion is well known, but the exact details are constantly changing behind the scenes.

we're still trying to figure out things internally regarding these "top tweets" / "popular tweets" / "relevant tweets", but, as always, one could just connect to the streaming API and get "true real time" tweets for "earthquake".

Maybe I could, but my 70 year old other couldn't.  I also was talking from a users point of view, not a developers, and even for a develper, you might just want the data a little faster than you could knock up the working code to check the streaming API. 
At the moment, with 3-4 tweets from "popular" at the top, it's not too much of a problem, but my worry is that twitter intend to roll out the popularity algorithm to larger and larger chunks of search, thus losing the real time search aspect of which it should be proud.

[Abraham Williams]

On Tue, Apr 6, 2010 at 09:31, Raffi Krikorian <ra...@twitter.com> wrote:

all in all - i hope a lot of you are coming to chirp, as i would absolutely happy to have this conversation in person over some beers :P

How about orange juice for those of us who don't drink? :-P

Abraham

--
Abraham Williams | Community Advocate | http://abrah.am
PoseurTech Labs | Projects | http://labs.poseurtech.com
This email is: [ ] shareable [x] ask first [ ] private.

[Dewald Pretorius]

Let's not kid ourselves. This change to "relevant" tweets is ad
revenue related, driven by a fear that Google will siphon off too many
search queries.

2 cents. *clink-a-ling*

[Marcel Molina]

While we should never kid ourselves, we should also try not to be sensationalist about things. Conspiracy theories aside, as Twitter gets more and more users, search results sorted strictly by time can in a lot of cases provide massive velocity that is very noisy and not very relevant. Sometimes the answer to "What's happening right now?" 

Here's an example: http://skitch.com/marcelmolina/n7thi/picture-5

The "most recent" tweets are still available Dewald. We aren't hiding them from you. They are right there. If you are more interested in @Evilknievel213 or @iHollywoodDance then you might be a little miffed that you have to scan past two results that are more "newsworthy" and a I would posit in most cases a more compelling answer to the question "What's happening right now?". 

If your issue here is with search.twitter.com as an end user and not the API then perhaps this forum has ceased to be the optimal place to share your feedback. We're not trying to ruin your search experience. We're trying to improve it by helping you wade through the noise. If you prefer to not have help wading through the noise you are the 20% case.

We're not monetizing earthquakes... 

--
To unsubscribe, reply using "remove me" as the subject.

--

[Dewald Pretorius]

"The "most recent" tweets are still available Dewald."

The impression I formed was that the entire search experience was
going to be converted over to "relevant" tweets at some point in time.
I.e., all returned tweets will be picked for relevance and time-sorted
tweets will not be shown.

Anyway, never mind. I've suddenly found something to do (taking down
the Christmas decorations), so I will now STFU.

[M. Edward (Ed) Borasky]

On 04/06/2010 09:31 AM, Raffi Krikorian wrote:
> all in all - i hope a lot of you are coming to chirp, as i would absolutely
> happy to have this conversation in person over some beers :P

Black coffee for me, decaf if we're doing this at the "hack session /
unconference" ;-)

--
M. Edward (Ed) Borasky

borasky-research.net/m-edward-ed-borasky

[Taylor Singletary]

Hey everyone,

My job title doesn't matter much. I do what I can and what needs to be done, whether that's being a contributing programmer on upcoming platform features, thoroughly testing an API before launch, analyzing implementations for spec compliance, communicating to and with the developer community, working closely with partners, writing documentation, or otherwise. My focus is on making the developer experience a positive one regardless of what bucket you fit into (hobbyist, corporate contributor, research scientist, or entrepreneur, or another lovely bucket). I might do that through building internal tools that make it more efficient and scalable for us to support you, I might do that by helping people out here who have questions, and I certainly might do that by channeling feedback generated in this particular segment of the developer community back to internal teams. 

When answering questions or engaging in discussions on this forum, I try to answer specific questions that are representative of the whole. I might not answer your specific question, but it's likely I'll answer a similar question with a response that would also apply to your own. Sometimes I will be intentionally obtuse. Often I will be overly verbose. If I don't perceive that I have something meaningful or valuable to add to a conversation or argument, I won't likely respond.

We're listening. You're always a factor in the decision making process. Sometimes the community can help change a decision mid-flight (like us deciding to find another way to keep public_timeline alive, despite our desire to deprecate). There will be other times that we'll make a decision that's not in alignment with the perceived popular opinion. All of these things are true. I'll do my best to be transparent on our thought process when it's appropriate to do so; there are times when we won't make our intentions perfectly clear.

The Twitter API will change. You & I will change with it. This is abstract. This is concrete. This is not a surprise. This is not a pipe.

I'm still learning.

Taylor Singletary
Developer Advocate, Twitter
http://twitter.com/episod

[Andrew Badera]

Taylor,

Your job title very much does matter. Any respectable public/"open"
API publisher needs to be concerned with the needs, wants and feelings
of their developer community. If you are part of Twitter's effort to
address this concern, then you need to be doing certain things. If you
are not, then you probably should not be labelled as doing these
things in order not to produce misleading expectations among
aforementioned developer community.

From the sounds of things, you're somewhere between evangelist and
client services, but nowhere close to being in the ballpark of
developer advocate. I'm not saying you're not doing a good job, I'm
just saying you're not doing THAT job.

Unfortunately this just contributes to the idea that Twitter doesn't
care about the people who enabled its success, that it's grown too
big, too fast, to remember the little people, that it's all about the
big money and not at all about the community. I'm sure that's driven
in large part by Evil Investors, but somewhere at Twitter, someone
needs to take a stand and strike a balance. Apparently that's not you.

∞ Andy Badera
∞ +1 518-641-1280 Google Voice
∞ This email is: [ ] bloggable [x] ask first [ ] private
∞ Google me: http://www.google.com/search?q=andrew%20badera

[Dewald Pretorius]

Very well said, Andrew.

Taylor, a Developer Evangelist is supposed to be someone who is paid
by Twitter to represent the developers, speak on their behalf in
meetings and conversations, represent their interests even when those
interests are directly opposed to Twitter's, fight on behalf of the
developers, and proactively take actions that will further and protect
developer interests.

A Developer Advocate is in a way synonymous with a union shop steward.

I don't know if this is what you did at LinkedIn as their Developer
Advocate. If not, then they (not you) too missed the mark by assigning
to you the wrong task list.

If this is not what Twitter wants to pay you to do, then fine. Then
they must just not pretend to have a Developer Advocate by slapping
that title on somebody.

Titles matter, but they mean nothing if you're not doing what the
title implies.

With so many thousands of developers out there, as a true Developer
Advocate, you shouldn't have time to do coding, documentation, and
whatever else they have you doing.

Unfortunately I'm not familiar with Andrew's full employment history
and business background. But, I've been in the IT industry since 1980,
and I've been at Vice President level of a large IT consulting
company. Hence, with some things there is a slight possibility that I
may know a little about what I'm talking.

> >> Erdős- Hide quoted text -

[Dewald Pretorius]

Yikes, of course I meant to write Deveoper Advocate, and not Developer
Evangelist.

> > - Show quoted text -- Hide quoted text -

[Andrew Badera]

On Tue, Apr 6, 2010 at 7:51 PM, Dewald Pretorius <dpr...@gmail.com> wrote:
> Unfortunately I'm not familiar with Andrew's full employment history
> and business background. But, I've been in the IT industry since 1980,
> and I've been at Vice President level of a large IT consulting
> company. Hence, with some things there is a slight possibility that I
> may know a little about what I'm talking.

Freelancing/consulting since 1996, mix of consulting and fulltime
since 1998, including time at IBM, Xerox, Gannett, Xerox again, and
other less-familiar names ranging from raw startups to SMB to midsize
corps, generally in dev/engineering/lead roles. More recently, CTO of
two startups, one somewhat backburnered this past year with the
economy, one rather new, (months old) still stealth but crazy active
and approaching public beta.

More relevant perhaps, recently took on the role of Senior Client
Services Engineer for Apprenda Inc., a recently-funded (NEA) upstate
NY startup, and makers of SaaSGrid. Also responsible for engineering
three or four actively consumed, fairly mature APIs (with admittedly
relatively small userbases) over the past few years.

I've been on both sides of the API fence, provider and consumer. I've
seen great evangelism and great advocacy. I've also seen piss poor
planning resulting in piss poor results.

--ab

[Jaanus]

My oh my, what discussion about advocacy and what not. I think Taylor,
Raffi and everybody else from Twitter are doing a great job here and
everyone is eager to learn and they know they have ways to go. Let's
not get mean.

I'm with those who say injecting popular searches into the search API
results by Twitter still doesn't entirely make sense, given the way
the rollout/communication is handled. Here is the problem/conversation
in a nutshell:

Twitter: "We are going to inject popular search results into the
search API results, changing previous behavior that just returned
recent results."
Developers: "Wait a sec, this is a bad idea because of A, B and C.
Maybe you can version the API better or some such."
... time passes, nothing happens ...
Twitter: "Hi, we're starting to roll this out now."

I don't particularly care for the popular results either way and I
trust Twitter that it is good for users in the grand scheme of things,
but the API behavior change is disturbing. It would be great to work
against a fixed API target so that those who want search to work in a
particular way can just work against a given API version, but with
search, this is not an option, you only have one endpoint that's in
this kind of flux.

What I'm saying is Twitter as a company could just earn more developer
street cred and respect here by handling this in a more graceful way.
There comes a point in time where the "moving parts" argument as an
excuse to not follow good API practices gets somewhat old.

rgds,
Jaanus

[Dewald Pretorius]

Jaanus,

Nobody intended to be mean, and nobody put into question whether
everyone at Twitter is doing a good job.

As Andrew noted, it's just that the job of Developer Advocate is not
being done at all. I see no malice in that. I believe it is just a
misunderstanding or a lack of understanding of the role.

To boil it down to the simplest of levels, an advocate is a person who
pleads for a cause or propounds an idea.

Hence, a developer advocate speaks, pleads, or argues in favor of
developers, particularly when their needs, wishes, desires, or
interests diverge from the needs, wishes, desires, or interests of
Twitter.

[Raffi Krikorian]

Hence, a developer advocate speaks, pleads, or argues in favor of
developers, particularly when their needs, wishes, desires, or
interests diverge from the needs, wishes, desires, or interests of
Twitter.

(which taylor does, btw) 

[John Kalucki]

I'd have to say that everyone from Twitter who posts on this list is very much a "Developer Advocate" and brings the concerns and viewpoints of the developer community as a whole into every meeting and decision. If there's ever an internal tension between a competing priority and the developer ecosystem, you can be assured that someone from this list will be taking the ecosystem into account, if not explicitly taking the ecosystem's side.

OTOH, this is a complex system, a diverse ecosystem and a complicated business. Most choices are win-win for everyone, but sometimes there are shades of gray and there are some non-winners and sometimes even some flat-out losers. In more than a few cases I hear gripes from some devs about changes that are making other devs jump for joy.

-John Kalucki
http://twitter.com/jkalucki
Infrastructure, Twitter Inc.

[Allan Hoving]

The interesting thing I'm finding is that if I try to do anything that elevates "popular" or "relevant" tweets, it causes the results to appear less dynamic, more static, less lively, more dead. And that's bad for the user experience.

Allan Hoving

http://www.thefrequency.tv