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:
> 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.
>
>
>
> On Tue, Apr 6, 2010 at 6:11 AM, Dewald Pretorius <dpr...@gmail.com> wrote:
> > 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.
>
> > On Apr 6, 9:47 am, 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.
>
> > > On Apr 6, 2010, at 4:28 AM, 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.
>
> > > > 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
> > > >>    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!
>
> > > >> On Mon, Apr 5, 2010 at 8:28 PM, Orian Marx (@orian)
> > > >> <or...@orianmarx.com>wrote:
>
> > > >>> 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
> > > >>>>> [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:
> > > >>>>>> 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
>
> ...
>
> read more »- Hide quoted text -
>
> - Show quoted text -


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

Reply via email to