November 14 2007 Conference Call: Difference between revisions
Joe.andrieu (talk | contribs) (→Notes) |
Joe.andrieu (talk | contribs) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 34: | Line 34: | ||
The Alan Document | The Alan Document | ||
===Public Call?=== | ===Public Call?=== | ||
November 21 is the next public call. We will open it to a wider group. We discussed the challenges of that and generally agreed to try managing trollish behavior on an | November 21 is the next public call. We will open it to a wider group. We discussed the challenges of that and generally agreed to try managing trollish behavior on an exception basis. If that becomes too much, we can revise our approach. | ||
===Alan Document=== | ===Alan Document=== | ||
Organized by "Modules". But in some conversations, we prioritize by Use Case. In other cases, it's Standards. Which should it be? | Organized by "Modules". But in some conversations, we prioritize by Use Case. In other cases, it's Standards. Which should it be? | ||
| Line 50: | Line 51: | ||
There are multiple technologies we can use to implement particular practices. As long as we can come up with how compliance can be measured. | There are multiple technologies we can use to implement particular practices. As long as we can come up with how compliance can be measured. | ||
Technology looking for a market. Product/market fit is the critical item. AttentionTrust, APML, OpenSocial, Jabber, PKI. | Technology looking for a market. Product/market fit is the critical item. AttentionTrust, APML, OpenSocial, Jabber, PKI. Use cases is what made user-identity work in contrast to what came before. | ||
Use cases that answer questions of how do we do a particular use case with a particular module? This will ultimately be an iterative process... the more we learn about use cases, the clearer we see the modules which help us understand the use cases better. | |||
Let's put together a list on the wiki of potential use case and vet, explicitly, which are potential VRM and which are not--and why. That will boil down to a specific set of principles pretty quickly. | |||
==Next Meeting== | ==Next Meeting== | ||
November 28, 2007 | November 28, 2007 | ||
[[category:conference call]] | [[category:conference call]] | ||
Latest revision as of 14:00, 14 November 2007
Conference Call Notes
Drafted by Joe Andrieu, November 14, 2007
IRC
- vrm at chat.freenode.net
Other Calls
Attendees
- Joe Andrieu
- Dean Landsman
- Iain Henderson
- Charles Andres
- Chris Carfi
- Drummond Reed
- Alan Mitchell
Notes
Wither Inverse of CRM
Should VRM be constrained/defined by calling in the inverse of CRM?
Inverse is an easy introduction, but has limits.
Circular buying process, ignorance, education, transaction, to sustained relationship. Otherwise we get laser focused on the transaction... and we need a broader palette (and palate!).
Definitely need to be more than transaction.
At the same time, the reciprocal of CRM, if viewed as Marketing, Sales, and Customer Support, itemizes three foci, entirely from the vendors perspectives. And yet, if we look at it from the individual's perspective, those are not necessarily the things we are looking for.
Agenda Items for F2F
Mission Plan Org. Structure The Alan Document
Public Call?
November 21 is the next public call. We will open it to a wider group. We discussed the challenges of that and generally agreed to try managing trollish behavior on an exception basis. If that becomes too much, we can revise our approach.
Alan Document
Organized by "Modules". But in some conversations, we prioritize by Use Case. In other cases, it's Standards. Which should it be?
Historically, a lot of standards actually start as products.
One challenge with "standards" is that no matter how much you have in place, you still need to impact business practices, not just bits on the wire. Typically one company starts to get traction and starts pushing a particular implementation /as standard/...
The earlier we get to the VRM principles that we won't sacrifice.
Then we can work through specific use cases.
Use cases always come first to spec the set of things we want to cover. But with XRI/XDI we had way too many use cases, so after 4-5 months we had to reduce to a set of principles and build from there.
There are multiple technologies we can use to implement particular practices. As long as we can come up with how compliance can be measured.
Technology looking for a market. Product/market fit is the critical item. AttentionTrust, APML, OpenSocial, Jabber, PKI. Use cases is what made user-identity work in contrast to what came before.
Use cases that answer questions of how do we do a particular use case with a particular module? This will ultimately be an iterative process... the more we learn about use cases, the clearer we see the modules which help us understand the use cases better.
Let's put together a list on the wiki of potential use case and vet, explicitly, which are potential VRM and which are not--and why. That will boil down to a specific set of principles pretty quickly.
Next Meeting
November 28, 2007