[Council] Fwd: Re: Quick poll on Activity Streams 2.0

Peter Saint-Andre stpeter at stpeter.im
Tue Jun 4 16:33:50 UTC 2013


Some interesting reflections on spec development from the Activity
Streams list...


-------- Original Message --------
Subject: 	Re: Quick poll on Activity Streams 2.0
Date: 	Tue, 04 Jun 2013 16:01:40 +0000
From: 	Chris Messina <chris.messina at gmail.com>
Reply-To: 	activity-streams at googlegroups.com
To: 	activity-streams at googlegroups.com <activity-streams at googlegroups.com>



I've been lurking/silent for like, forever, but given Evan's original
request, just thought I'd add my two cents, based on observing
communities like OpenID and OAuth, which both had follow-on 2.0 specs.

1. *Optics matter.* There is some real desire to have a stable 1.0 that
people can adopt, implement, and make use of. This helps people feel
like there's a "there there" — i.e. a product that people can use
without worrying about things changing underneath their feet.

2. *Sustaining velocity is critical.* While stability is symbolically
important, momentum and velocity is also important, lest the 1.0 be
treated as "The End", leading to a project going dormant (or the
perception thereof), which would actually harm the adoption we'd hope to
see as a result of #1.

3. *Maintaining integrity over time.* I don't know how much AS 1.0
deviates from where we started, but I imagine that the outline tracks
pretty closely to what I outlined in 2008:

http://factoryjoe.com/blog/2008/06/11/adding-richness-to-activity-streams/

... and my original objective for the project still seems appropriate:

"The basic premise is this: lifestreams, alternatively known as
“activity streams”, are great for discovering and exploring social
media, as well as keeping up to date with friends (witness the main
feature of Facebook and the rise of FriendFeed
<http://ft.com/cms/s/0/4bb053f2-364e-11dd-8bb8-0000779fd2ac.html>). I
suggest that, with a little effort on the publishing side, activity
streams could become much more valuable by being easier for web services
to consume, interpret and to provide better filtering and weighting of
shared activities to make it easier for people to get access to relevant
information from people that they care about, as it happens."

So, given that — I'd hope that any 2.0 work (or 1.1 work, since a
dot-release would support #2 above without leading to people holding off
for 2.0) would maintain consistent with these goals — especially the
part about simplicity. If anything, 2.0 work should refocus features or
scope, rather than /add/ new things (unless those new things bolster the
integrity and core usefulness of the product).

4. *Clear marketing can help attenuate confusion.* If there is desire to
work on a 2.0 (which would need to be sponsored by more than one
/implementing/ individual, I'd think), I'd be very intentional and
careful about how 1.0 is presented versus 2.0. I wouldn't say that we
got it 100% right with OAuth.net, but we did try to make the version
status pretty clear — but OAuth is in many way the anti-pattern,
compared with, say, jQuery, or another project that has sustained
momentum and development.

5. *Smaller, regular, incremental releases are better.* I think I've
seen this in Apple over the past couple years, but OS X is basically
"done". They've subsequently sped up dot releases and kept the changes
pretty minimal — making it easier to get people to adopt the changes and
"keep up". I think spec work can learn from this. So — it seems like you
could take on 1-2 improvements for 2.0, set a date like 2 months out and
shoot for that — rather than bloating the spec with tons of new stuff,
treat 1.0 as your foundation, and use subsequent releases to make
constant improvements to it, rather than treating the 2.0 as an
opportunity for a rewrite or overhaul (many projects seem to die in the
2.0 rewrite).

6. *Nothing drives adoption like adoption.* All that said (which implies
moving forward with 2.0 work) is predicated on seeing real adoption of
1.0. I wouldn't be afraid of moving forward or breaking 1.0 clients
(that's the nature of software) but I would be worried about
jeopardizing adoption and implementation by moving too quickly forward
before the dust has settled and you've gotten good feedback from people
who are new/unfamiliar with the spec.

Anyway, feel free to ignore this — I've been away far too long and these
things may also be totally obvious to you guys — but I just thought I'd
chime in since it's been great to see the work continue here, even in
light of Schema.org/JSON-LD. (Also, it should go without saying, but the
above represents my views, and not that of my employer
#alwayswantedtosaythat).


On Mon Jun 03 2013 at 11:37:33 AM, James M Snell <jasnell at gmail.com
<mailto:jasnell at gmail.com>> wrote:

    Evan,

    Given the extremely positive overall response that I've received since
    posting my original idea, it's fairly obvious to me that some new work
    is warranted. That said, what I posted was just an initial idea of how
    it could go and not a completed spec. I personally think the proposed
    syntax has a number of advantages relative to 1.0 but that's just my
    personal opinion based on my own personal implementation experience
    (please do not forget that I'm not just writing specs here, I'm
    implementing this stuff too). Everything that I've put into this draft
    is based directly on lessons I've learned from implementing 1.0.
    Also, please keep in mind that, as an *initial* *proposal*, it's not
    the finished product. If folks want, I can easily go back and change
    the @id and @type thing back to id, verb and objectType, and those
    folks who want the JSON-LD support can use that specifications built
    in aliasing to get them the rest of the way. That doesn't rule out the
    other syntax improvements that are made tho... things like the
    improved internationalization, less verbose syntax, first class
    linking, first class support for external vocabularies... these are
    all things that *implementation* experience has demonstrated to me are
    worthwhile.

    - James

    On Sun, Jun 2, 2013 at 10:24 AM, Evan Prodromou
    <evan.prodromou at gmail.com <mailto:evan.prodromou at gmail.com>> wrote:
    > I'd love to get a +1/-1 on whether we should start a new round of
    > specification work on Activity Streams JSON.
    >
    > My vote is -1, for these reasons:
    >
    > It's going to be a big distraction for a lot of people who have
    other things
    > to do.
    > We don't have well-known issues that have come up out of
    implementation
    > problems.
    > We need stability in order to get more implementations. Nobody
    likes to
    > chase a moving target.
    > FUD - having a 1.0 = stable and 2.0 = pair of specs means
    developers have to
    > choose. Nobody likes to choose.
    > The benefits of the 2.0 proposal are slim at best; it's not clear
    what the
    > gain will be, and definitely not clear that it outweighs the
    problems.
    > I don't think competition with schema.org <http://schema.org> is a
    good reason to work on a
    > spec.
    >
    > I'd love to hear if I'm the only person who feels this way.
    >
    > -Evan
    >
    >
    > --
    > You received this message because you are subscribed to the Google
    Groups
    > "Activity Streams" group.
    > To unsubscribe from this group and stop receiving emails from it,
    send an
    > email to activity-streams+unsubscribe at googlegroups.com
    <mailto:activity-streams+unsubscribe at googlegroups.com>.
    > To post to this group, send email to
    activity-streams at googlegroups.com
    <mailto:activity-streams at googlegroups.com>.
    > Visit this group at
    http://groups.google.com/group/activity-streams?hl=en.
    > For more options, visit https://groups.google.com/groups/opt_out.
    >
    >

    --
    You received this message because you are subscribed to the Google
    Groups "Activity Streams" group.
    To unsubscribe from this group and stop receiving emails from it,
    send an email to activity-streams+unsubscribe at googlegroups.com
    <mailto:activity-streams+unsubscribe at googlegroups.com>.
    To post to this group, send email to
    activity-streams at googlegroups.com
    <mailto:activity-streams at googlegroups.com>.
    Visit this group at
    http://groups.google.com/group/activity-streams?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.


-- 
You received this message because you are subscribed to the Google
Groups "Activity Streams" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to activity-streams+unsubscribe at googlegroups.com.
To post to this group, send email to activity-streams at googlegroups.com.
Visit this group at http://groups.google.com/group/activity-streams?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.






More information about the Council mailing list