What's left to do?

[Simon Wistow]

I feel like the general shape of everything is in place but that
momentum has slowed down (maybe I'm just projecting though).

Is there a list of stuff to do in order to be able to go more public
with a draft spec and then allow a bunch of us to go do trial
implementations and see how everything pans out?

Off the top of my head:

* Finalise list of initial verbs. Note, not a definitive list, just a
first cut.
* Ditto nouns.
* Confirm format of vendor preferred terms (i.e "tweet", "tweeted" and
"dugg") for nouns and verbs.
* Format of activity:object - I favour having a full entry or person or
link as a sub-element, Martin doesn't (and I totally see his points
as well). I can't remember if this got resolved or not.
* Whether to allow multiple events in one entry (I think the only plus
side to this is that "Friend Feed do it")
* Reference stream (+ a nice html version of it showing various bits of
collapsing)

[Monica Keller]

Yeah MySpace's initial version is out in prod yay (email me if you
want to be whitelisted to try it.)
with some verbs using activitystrea.ms namespace and some not and they
are important ones too like Connect.

Which pretty much means partners have to use some myspace
terminology...
lets get it standarized or standarize how to submit new ones

I think we need more of a working meeting or dev jam ? How about late
feb ?

Does anyone have any activity streams publishers they would be willing
to expose ?

[Chris Messina]

There's still momentum -- I think we're just waiting for the next rev of the spec -- especially now that MySpace has gone live (nice work Monica! -- would love take a look).

Part of this will involve getting activitystrea.ms up and running and letting people register new verbs... I think we need to think about the best way to allow emergent verb types to take hold, but to somehow restrict the core list of verbs to only those where there are -- say -- three or more implementations.

That way the verbs under the activitystrea.ms/schema can be vendor neutral but still provide a useful, central service for folks who want to publish a "known type" of verb...

In the meantime, MySpace, Microsoft, Facebook and others can create their own custom verb types, using their own namespaces, and over time we would migrate them to the core namespace. 

Does that make sense? I think that's really the best way to balance being too vendor-specific to start and to also have a migration path for the most popular verbs.

Chris

P.S. Michael Richardson and I are working on a small app that produces AS-compliant feeds.

--
Chris Messina
Citizen-Participant &
 Open Web Advocate-at-Large

factoryjoe.com # diso-project.org
citizenagency.com # vidoop.com
This email is:   [ ] bloggable    [X] ask first   [ ] private

[Michael Richardson]

I've been concerned about the restrictive set of types that are up
there right now.

> Which pretty much means partners have to use some myspace
> terminology...
> lets get it standarized or standarize how to submit new ones

I would love to see an http://axschema.org style site for submitting
new types, and other things. I don't think we need to restrict it,
though I can definitely see the pros of doing so. I'd much rather
give people the ability to add things. We can always build in an
approval mechanism.

[Chris Messina]

I think that activitystrea.ms should be the equivalent of axschema.org.

Note that, to my knowledge, axschema.org has not taken off (to date, there have only been 30 messages posted to the AXSchema list -- and I don't know that any new schemas have been generated).

That said, it is critical that we figure this out.

If every vendor simply invents their own verb types and registers their schema, I don't know that we're making progress.

There needs to be a limited set of verbs that parsers can support -- at least to start -- and then we can add more over time -- perhaps maintaining libraries and/or templates for how to treat different kinds of verbs/objects.

Perhaps a roadmap would be easier to digest and provide more assurance. For example, by Draft 3 (we're at Draft 1 now, soon to be Draft 2) it would be great if we supported 15-40 verbs. For now, we're starting with 5-6 just to keep the conversation focused on HOW, not what... (because we quickly get into bikeshedding and yak shaving with determining WHICH verbs to support).

Still, with Draft 3 and a bunch of verbs, we need a way for vendors to express/point to their set of proprietary verbs... and I think that can be done on activitystrea.ms....

http://activitystrea.ms/schema/facebook/1.0/poke

http://activitystrea.ms/schema/myspace/1.0/review

http://activitystrea.ms/schema/windowslive/1.0/upload

etc.

Different groups could reserve namespaces -- not sure what the best approach is -- if we should do this by vendor or by class of verb -- but this is generally what I'm thinking for managing/channeling verb proliferation.

Chris 

[Martin Atkins]

Chris Messina wrote:
> There's still momentum -- I think we're just waiting for the next rev of the
> spec -- especially now that MySpace has gone live (nice work Monica! --
> would love take a look).
> Part of this will involve getting activitystrea.ms up and running and
> letting people register new verbs... I think we need to think about the best
> way to allow emergent verb types to take hold, but to somehow restrict the
> core list of verbs to only those where there are -- say -- three or more
> implementations.

As far as "registering" new verbs goes, my preference would be for that
to take place by writing specifications, not by some kind of web-based
land-grab.

Saying "I use the verb 'doodled'" is not useful unless there is a
detailed description of what it means and how it's used.

Writing a spec gives the community the opportunity to give feedback.

By all means vendors can feel free to experiment in their own
namespaces, especially with new object types for which the spec defines
a sensible fallback behavior for handling unknown ones. (Verbs are a
little more tricky, of course.)

[Chris Messina]

On Sun, Feb 1, 2009 at 12:37 PM, Martin Atkins <ma...@degeneration.co.uk> wrote:

Chris Messina wrote:
> There's still momentum -- I think we're just waiting for the next rev of the
> spec -- especially now that MySpace has gone live (nice work Monica! --
> would love take a look).
> Part of this will involve getting activitystrea.ms up and running and
> letting people register new verbs... I think we need to think about the best
> way to allow emergent verb types to take hold, but to somehow restrict the
> core list of verbs to only those where there are -- say -- three or more
> implementations.

As far as "registering" new verbs goes, my preference would be for that
to take place by writing specifications, not by some kind of web-based
land-grab.

+1. I think we need to spell out what a good "verb spec" would look like then -- with a mandate that examples in the wild must be provided.

 

Saying "I use the verb 'doodled'" is not useful unless there is a
detailed description of what it means and how it's used.

Writing a spec gives the community the opportunity to give feedback.

By all means vendors can feel free to experiment in their own
namespaces, especially with new object types for which the spec defines
a sensible fallback behavior for handling unknown ones. (Verbs are a
little more tricky, of course.) 

While I agree with you -- we need to strike a balance between making this easy for publishers that are likely to go hog-wild with verbs unless we can provide them a benefit for reusing existing verb types (namely, compatibility and support in aggregators). We also need to be sensitive to developers and product teams that are going to ship verbs in their products and not really take an interest in this whole "spec'ing overhead" process...

I think there should be a good lifecycle of experimentation, extending one's own namespace, and then, after, again, seeing behavior in the wild over time, develop, as you've suggested a way to specify how different verbs can and should be used (based on observed behavior) and how aggregators should treat such verbs when they show up.

I've mocked up a page that could be used for describing a basic verb:

http://www.flickr.com/photos/factoryjoe/3244608669/

If we did this, or required this, for each verb in the core schema, I think we'd be in good shape.

Chris

--
Chris Messina
Citizen-Participant &
 Open Web Advocate-at-Large

factoryjoe.com # diso-project.org
citizenagency.com # vidoop.com

This email is:   [X] bloggable    [ ] ask first   [ ] private

[Michael Richardson]

>>> > There's still momentum -- I think we're just waiting for the next rev of the
>>> > spec -- especially now that MySpace has gone live (nice work Monica! --
>>> > would love take a look).
>>> > Part of this will involve getting activitystrea.ms up and running and
>>> > letting people register new verbs... I think we need to think about the best
>>> > way to allow emergent verb types to take hold, but to somehow restrict the
>>> > core list of verbs to only those where there are -- say -- three or more
>>> > implementations.
>>>
>>> As far as "registering" new verbs goes, my preference would be for that
>>> to take place by writing specifications, not by some kind of web-based
>>> land-grab.
>>
>> +1. I think we need to spell out what a good "verb spec" would look like then -- with a mandate that examples in the wild must be provided.

I agree that a web-based land grab is not what we want - I'm hoping
for a process that involved community discussion, perhaps done over
the mailing list, perhaps with a simple voting app, whatever - that
would enable people to get a needed schema type up without a lengthy
spec writing process while still providing feedback and community
involvement. Having a web front to this process, even if it's just a
page with "Email this list to get the discussion started," (maybe a
form with the fields Chris put in his mockup below and example values)
would be very nice.

>>> Saying "I use the verb 'doodled'" is not useful unless there is a
>>> detailed description of what it means and how it's used.
>>>
>>> Writing a spec gives the community the opportunity to give feedback.
>>>
>>> By all means vendors can feel free to experiment in their own
>>> namespaces, especially with new object types for which the spec defines
>>> a sensible fallback behavior for handling unknown ones. (Verbs are a
>>> little more tricky, of course.)
>>
>> While I agree with you -- we need to strike a balance between making this easy for publishers that are likely to go hog-wild with verbs unless we can provide them a benefit for reusing existing verb types (namely, compatibility and support in aggregators). We also need to be sensitive to developers and product teams that are going to ship verbs in their products and not really take an interest in this whole "spec'ing overhead" process...
>>
>> I think there should be a good lifecycle of experimentation, extending one's own namespace, and then, after, again, seeing behavior in the wild over time, develop, as you've suggested a way to specify how different verbs can and should be used (based on observed behavior) and how aggregators should treat such verbs when they show up.
>>
>> I've mocked up a page that could be used for describing a basic verb:
>> http://www.flickr.com/photos/factoryjoe/3244608669/
>>
>> If we did this, or required this, for each verb in the core schema, I think we'd be in good shape.

I like the mockup that Chris put up. I would much rather have the
process be looser and something we're involved in, something we can
influence and guide along, than have it be "Oh, this doesn't really
fit what we want, so we'll just make our own stuff." Not saying that
it's an either-or, just that it would be good to have a lower barrier
to entry.

[Michael Richardson]

On Feb 1, 2009, at 9:17 AM, Simon Wistow wrote:

<...>

> * Whether to allow multiple events in one entry (I think the only plus
> side to this is that "Friend Feed do it")

I'm personally -1 on this.

> * Reference stream (+ a nice html version of it showing various bits of
> collapsing)

I'm working on something along these lines, I'll make more of an
announcement when it's further along, but if you want to help out let
me know.

[Evan Prodromou]

On Feb 1, 12:41 pm, Monica Keller <monica.kel...@gmail.com> wrote:

> I think we need more of a working meeting or dev jam ? How about late
> feb ?

I'll be in the Bay Area from 23 Feb -> 1 Mar and I'd love to be there
for such a meeting.

-Evan

[Martin Atkins]

Michael Richardson wrote:
>
> I agree that a web-based land grab is not what we want - I'm hoping
> for a process that involved community discussion, perhaps done over
> the mailing list, perhaps with a simple voting app, whatever - that
> would enable people to get a needed schema type up without a lengthy
> spec writing process while still providing feedback and community
> involvement. Having a web front to this process, even if it's just a
> page with "Email this list to get the discussion started," (maybe a
> form with the fields Chris put in his mockup below and example values)
> would be very nice.
>

As far as I can tell, the "lengthy spec-writing process" is lengthy
because of several desirable things:

* Feedback and discussion, leading to multiple drafts.
* The need to define things in detail for maximum interoperability.
* Time spent researching and evaluating possible solutions.

Of course, future specs can use past specs as a template or example of
how to write a good spec. The AtomActivity spec today is based on the
structure of the Atom Threading Extensions spec, for example.

[Michael Richardson]

On Feb 2, 2009, at 1:23 PM, Martin Atkins wrote:
> As far as I can tell, the "lengthy spec-writing process" is lengthy
> because of several desirable things:
>
> * Feedback and discussion, leading to multiple drafts.
> * The need to define things in detail for maximum interoperability.
> * Time spent researching and evaluating possible solutions.
>
> Of course, future specs can use past specs as a template or example of
> how to write a good spec. The AtomActivity spec today is based on the
> structure of the Atom Threading Extensions spec, for example.

You are, of course, absolutely right. These are all things that
definitely require feedback from the community and discussion and most
likely multiple drafts.

I'm still a proponent of having something that makes the process clear
as to how one goes about getting something in our namespace, something
that might even guide them partway though. However, as for the actual
process... yeah, I'm with you there.

[Chris Messina]

I second what both of you guys are saying.

The specing process should be clear and obvious or else people won't bother — and like I said, they'll just do their own thing, outside the scope of Activity Streams. Maybe it's not a big deal, but clearly the easier and more transparent we make participation, the more likely we'll see good adoption.

Even if the process ends up being longer than going all Highlander-style ("There can only be one!"), at least contributors to the process will have their work vetted and cross-referenced against existing verbs, etc.

Chris

--
Chris Messina
Citizen-Participant &
 Open Web Advocate-at-Large

factoryjoe.com # diso-project.org
citizenagency.com # vidoop.com