Re: Look at other XG charters...

Hey there,

a few belated answers to the threads from last week.

Le 11 févr. 09 à 00:03, Harry Halpin a écrit :

>
> Also, it may be educational to look other Incubator Group's charters.
> See Emergency Interoperability Incubator Group [1] and Rich Web
> Backplane Incubator Group [2].
>
> Note that *none* of them are broken into task forces with separate
> telecons, and in general have from 1-5 deliverables, with an average  
> of
> about 3 deliverables, of which one is *always* a report for future
> activity.

I would argue that our domain, the “Social Web” as we voted to call  
it, is significantly larger than the domains covered in those previous  
XGs you cite as examples.

> In general, it's safer policy to aim small and then grow
> rather than to start with some large bureaucratic structure based on
> rather ill-defined terminology

Again. What is more bureaucratic ? 2-3 XGs, each with its draft  
charter, its approval process and its chairs or one single XG?

I agree with the basis of your argument though. Let's start small,  
identify 2-3 Task Forces we have editors for and put the rest in a  
todo-list or a similar section in the Charter, as Karl proposed.

> (Can someone give me a succinct and
> substantive difference between distributed architectures and
> interoperability? Or contextual data and user experience?) and  and
> expect it to grow.

1) Interop is a part of Distributed Architectures.
Interop only worries itself about same-level, horizontal communication  
between implementations of a stack. Think Two nodes communicating over  
TCP in the OSI stack. Or, as we drafted it out during the workshop,  
finding ways to translate between two protocols or data formats which  
serve the same purpose and are at the same level in stack.

In my opinion, Distributed Architectures also concerns itself with, at  
least:
a) vertical communication between elements of the stack (TCP working  
with IP in the OSI stack).
b) potential for the distribution of a final end-user service across  
nodes. Example: having a blog and sub-contracting the management of  
your comments to a service like Disqus [2].

Now, this is just my view. For the sake of starting work soon, I'd  
rather let the volunteer editors decide whether they all want to merge  
those or not. As long as we are aware of the specificities of each  
field, I'm sure we can put great work together on that front,  
whichever way.


2) Contextual Data is only one way through which User Experience can  
be studied, extended or otherwise “improved”. Conversely, Contextual  
Data has challenges and objectives which are not all linked to  
improving User Experience: for example, there is a lot for operators  
to gain in terms of datamining through Contextual Data.

That's just off the top of my head. Again, it's probably better to  
leave the relevant volunteer editors comment and obviously make the  
final call on this themselves.


[snip]


Cheers,
Tim


[1] http://disqus.com/

- - - - - - -
Tim Anglade | directeur, pôle « Turbulences » | af83
42, boulevard de Sébastopol | 75003 Paris | France
1436, Howard St | San Francisco | CA 94103 | USA
Tel : +33 1 42 72 33 32
Mob : +33 6 35 92 77 58
skype : tim_anglade
Web : www.af83.com

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

Received on Monday, 16 February 2009 17:21:36 UTC