Proposal to merge this group into Technical.
Julian Bond
people feel that there's a lot of overlap and that the participants are
the same.
The plan is to do this in 5 days assuming there is no extreme dissent.
Do speak up if you feel this is a mistake.
--
Julian Bond E&MSN: julian_bond at voidstar.com M: +44 (0)77 5907 2173
Webmaster: http://www.ecademy.com/ T: +44 (0)192 0412 433
Personal WebLog: http://www.voidstar.com/ skype:julian.bond?chat
Runs Better Without Windows
Paul Jones
Whilst a lot of the participants are the same, there is a decent delineation in terms of the desired output. It *should* also allow for the people with limited time to more effectively manage their participation.
Julian Bond
>I personally do think this is a mistake...
>
>Whilst a lot of the participants are the same, there is a decent
>delineation in terms of the desired output. It *should* also allow for
>the people with limited time to more effectively manage their
>participation.
OK. So what is the delineation? How are they different? because I can't
see it. Or to put it another way what is the purpose of the
Implementation group that makes it sensible to split it out.
Mark Shiu
I think this group might be useful when we get down to implementing DP.
Meanwhile, we can define what the purpose of the two groups.
What I think Technical group is the overall view of DP. It provides and discuss the use of technologies, such as RSS/Atom.
While Implementation group maybe more focus on languages, and problems between bridging different/overlap features.
Any other thought? Please feel free to comment.
Thanks
Mark Shiu
Mike Reynolds
However, just to mention it, my concern is that general talk of "how
well Company X" has implemented DP will get lost in a swamp of
technical details such as "I having problems with getClass().getName()
+ '@' + Integer.toHexString(hashCode()), can you help?"
But if I focus on the kinds of things people will need to talk about
if they are actually doing DP, then the merger makes perfect sense.
Joaquin Salvachua
I am in favour of the merge.
I think that may be the same set of people with three hats:
* having a written spec for the group.
* have a set of implementations for it.
* have some set of validation for implemetations to join the group.
So must have both outputs appart.
Joaquin
Julian Bond
"how well Company X has implemented DP" is either
1) An Evangelism issue. In which case it's off topic.
or
2) An Interoperability issue. In which case it's technical and on topic.
--
Julian Bond E&MSN: julian_bond at voidstar.com M: +44 (0)77 5907 2173
Webmaster: http://www.ecademy.com/ T: +44 (0)192 0412 433
Personal WebLog: http://www.voidstar.com/ skype:julian.bond?chat
Keeps On Killing For 3 Months
Richard Pendergast
i think the issue at the moment is not that there is no need for the
implementation action group (iag), but that nobody is doing anything
in the iag, and that even with responsibilities outlined, people are
not understanding the difference between the technical blueprint group
(tbg) and the iag.
its an issue relating to focus, filtering and concentration span.
for example, playing devils advocate here...
as an implementor, im not necessarily going to care, or want to get
involved in, the theoretical side of things or the development of best
practices. im looking for a dp compliance badge, and the credibility
that comes with it. i want my users to know that i care about them and
that for this reason i am now dp compliant. in all likelihood i will
be more interested in which plugins to use than which standards those
plugins are based upon. if the iag and the tbg combine, then there is
nowhere i can go that relates only to implementation, and im going to
have to sift through discussions such as saml vs openid that hold no
interest for me.
just to make things clear, these are not my thoughts. i am very
interested in the tbg, and the work being done there, but i know
personally, and professionally, a hell of a lot of others that would
fall into this example.
as i said earlier, the issue is not that there isnt a need for iag.
the issue is that there are actually no implementations working with
the iag. theyre either unaware of the group and off doing their own
thing, or simply couldnt be stuffed helping get it started.
put simply, i think there are two very distinct groups, and although
not perfect the respnsibilities associated with each show very
different needs.
eg. discussions relating to plugins vs discussion relating to standards
eg. discussions relating to libraries vs discussion relating to interoperability
etc
im actually a bit bummed by the fact that any ideas i have discussed
with others regarding this has been welcomed with open arms, only to
be dumped when i havent had the time to actively drive them (my wife
is once again in hospital). i thought dp was a collaboration...
i really have to say that im a bit concerned that there is a lot more
talk happening than action. im very much for dp, and will stick with
it until it comes about, but putting it very bluntly, ive had at least
6 people come to me and offer code only to get caught up in the skype
chats, the offline discussions and the movement to confluence.
infrastructure is only good if you use it. iag vs tbg vs gg? it doesnt
matter if nothing comes of it.
the best stuff ive seen come out of dp, apart from the great work
being done with the technical blueprint has been the piecemeal work
being done by young guys coming in for the first time and saying "im
already working on this and could use a hand". the iag should be
supporting these guys.
when candice gets out of hospital i will be coding something up
myself. im disappointed that i have to do this, as i would have
preferred to focus on working with other developers, supporting them,
and providing starting points and training materials, but the reality
is that i currently have nothing to show.
this discussion should be worked out as soon as possible and put to
bed so that the real work can be done. if we want the vendors to take
dp seriously, then we need to show that we can make something happen.
Julian Bond
13:57:40
>as an implementor, im not necessarily going to care, or want to get
>involved in, the theoretical side of things or the development of best
>practices. im looking for a dp compliance badge, and the credibility
>that comes with it. i want my users to know that i care about them and
>that for this reason i am now dp compliant. in all likelihood i will
>be more interested in which plugins to use than which standards those
>plugins are based upon. if the iag and the tbg combine, then there is
>nowhere i can go that relates only to implementation, and im going to
>have to sift through discussions such as saml vs openid that hold no
>interest for me.
There's some truth in this. It's just that personally I have a leg in
both camps so have trouble seeing the difference. As a Dev-Programmer
I'm actively trying to implement this stuff. As an intellectual exercise
and as a CTO, I'm trying to understand why I should implement this and
not that, what the design choices were and which of the many parallel
paths I should follow.
In something like the OpenID groups I'm not interested in building
libraries or designing the protocols but I do need to raise issues
related to the use of those libraries. And I end up questioning things
like the decision to build yet another profile schema and profile
description language.
Maybe there'll come a time when there'll be a similar split between
protocol design and actual implementation. But I don't think we're there
yet with DP.
And perhaps IAG simply hasn't reached critical mass yet. We could talk
about problems and war stories implementing the stuff in the best
practice docs. And I'm very happy to share experience in those areas.
Julian Bond
technical, but there's a huge amount in implementing and encouraging
other to implement what we've already got.
Just a thought.
Jacob Chapel
unsure of what course we should take. After reading everyones thoughts
and feelings on it, I believe the decision to be clear.
We should not prune or kill Implementation, it is still valuable, just
maybe not right at this moment. There will be a time, and soon, that
we will need to have a separation between the people that wish to
discuss the fine details of what specs to use and how, and that of the
people that want to use those results and learn how to comply with
what DataPortability is.
If we get rid of it now, we will have more problems down the road, but
I believe some action could be taken to get more activity here.
Instead of waiting for people to come to us to learn how to implement
dp, maybe we should head to them and push them towards that direction.
We have the first steps of the blueprint, and a lot of things that
could be implemented at basic levels to get started.
Julian put it this way, Implementation is like Evangelism for
developers. It is more than that, but right now we really could show
our worth by getting out there and using the research phase to push
people in the right directions.
So I extremely dissent against getting rid of Implementation. :)
Dan Brickley
>
> I'm for this merger.
>
> However, just to mention it, my concern is that general talk of "how
> well Company X" has implemented DP will get lost in a swamp of
> technical details such as "I having problems with getClass().getName()
> + '@' + Integer.toHexString(hashCode()), can you help?"
Existing software distributions, services, protocols and standards all
have lists, bug trackers etc already. Since I don't understand DP to
be a software development project, I'm happy having the lists folded
together...
Dan