Shameet
pkeenan
"Can we just meet up whenever most people can, videotape it and others
can watch to catch up and participate next time? Finding consensus on
meet times for this many people will probably never happen. Thoughts?"
Mark Kuznicki
I am encouraging people who are interested in leading ChangeCamp
projects to use this list and the wiki to find one another and
organize. I'm having moderate success with live-streaming and
recording meetings with ustream.tv.
So, the ChangeEngine folks should really start to think about who's
got a real passion for the project and want to form a tight little
crew. I see my role as one of providing support, context and
connections as needed.
We have the technology, all we need is people to step up and lead.
What's next??
Mark.
Thody
In an effort to keep up some kind of momentum on this, I'd like to
propose that we have a guaranteed meet next week. Let's survey for
availability, and just go with the best option. Whoever can't make it
can watch the video afterwards.
I'm also thinking since we all have such busy schedules, perhaps we'd
be best off to pick a regular day/time for bi-weeklies or monthlies so
that there's enough advance notice to slot them in.
Let's try to work out availability for next week (please weigh in
asap): http://www.doodle.com/participation.html?pollId=dm4rf2fypmuv3xgf
Thody
Was writing my post while you were writing yours...Would you prefer
that we start a new GoogleGroup for ChangeEngine to keep the clutter
out of the main ChangeCamp group?
Adam
Mark Kuznicki
I would use this main Group to find one another, engage stakeholders,
solicit feedback. Once things get going, you can fork to another
Group, but I'd take the time for the core team to find itself.
Also @changecamp on Twitter for anything you might want retweeting the
whole ChangeCamp community on Twitter.
Thanks for taking the initiative!
Mark.
Thody
meets. We're at Queen & Spadina, so it's fairly central location.
'
Adam
Adam Schwabe
well? I could probably swing early morning but my brain doesn't
usually start working creatively until at least 10/11.
Thody
Fixing it now...thanks Adam.
Thody
availability.
http://www.doodle.com/participation.html?pollId=dm4rf2fypmuv3xgf
Michael Allan
> Was writing my post while you were writing yours...Would you prefer
> that we start a new GoogleGroup for ChangeEngine to keep the clutter
> out of the main ChangeCamp group?
Is ChangeEngine another name for the Shame Engine?
http://changecamp.wik.is/Change_Projects/Shame_Engine
Twitterless,
--
Michael Allan
Toronto, 647-436-4521
http://zelea.com/
MarkRabo
Technical, UI/UX, marketing (or whatever makes sense at this stage).
Each team can meet separately and when we hold combined meetings,
there need only be some people representing each team.
Focusing might also stimulate our creativity and productivity, and if
some people can't make it one day we still move ahead.
There needs to be a definite scope for the project first, but we can
do that at the next meeting.
Michael Allan
> There needs to be a definite scope for the project first, but we can
> do that at the next meeting.
But do tell us *roughly* what it's all about, since we are
confused. :-)
Is ChangeEngine just another name for the Shame Engine?
Thody
will go a long way to help with scheduling for sure.
Thody
that transition actually took place. Anyone?
Adam King
for the project because it makes the concept a little too negative.
The tool will do more than shame people/gov, it can also be a way to
map solutions and constructive dialogue.
Adam King
Mobile: +1 519-774-0773
Skype: voiceofadamking
Twitter: http://twitter.com/sabbatical
Mark Kuznicki
of course includes public servants at the City and politicos. The
cheekiness of "ShameEngine" is pretty funny when you get the tone of
it, but it's just lost in text and online on its own, so I say dump it.
We're getting some good ideas for self-organization principles from
Tonya Surman's Constellation Model and from Gerry Kirk's Agile
coaching expertise. Have a look at Tonya's paper on the Constellation
Model, and watch the (114 minute long) live-stream capture of the
future of ChangeCamp strat session. She explains the model at 30:00 or
so.
http://wiki.changecamp.ca/StratPlan/StratDesign2
http://www.socialinnovation.ca/blog/open-sourcing-social-change-inside-constellation-model
Mark Kuznicki
ChangeCamp.ca
blog: http://changecamp.ca
Twitter: http://twitter.com/changecamp
email: chang...@remarkk.com
mobile: 416-994-2470
On 21-Feb-09, at 5:56 PM, Thody wrote:
>
Michael Allan
Adam King wrote:
>
> I think there's a movement away "Shame Engine" as the public moniker
> for the project because it makes the concept a little too negative.
> The tool will do more than shame people/gov, it can also be a way to
> map solutions and constructive dialogue.
Nice. And in parallel with that - measuring people's *agreement* to
those solutions - that's my own domain. The two domains (problem
transparency and solution consensus) are orthogonal. But I suspect
there'll be some important cross-domain relations, and some public
APIs to support them. In general, there's going to be an open
ecosystem of all this stuff... Which leads me to ask Mark for advice:
Mark Kuznicki wrote:
> So, the ChangeEngine folks should really start to think about who's
> got a real passion for the project and want to form a tight little
> crew. I see my role as one of providing support, context and
> connections as needed.
>
> We have the technology, all we need is people to step up and lead.
Re context: Is it too early to start thinking about the framework for
developing those public APIs? It's not a technical question, at this
point. It goes beyond any specific relations between Shamen and
Votorola, too. I'm guessing it's more a question of transparency - of
having an open and trustworthy process of standards development. My
thinking is explained here:
http://metagovernment.org/pipermail/start_metagovernment.org/2009-February/thread.html#1189
GoogleVotes monopoly vs. JoeVotes ecosystem
The reason why I think it's *not* too early, is because it would be a
huge boost for all of us change projects, if we had a way to come
together (technically), and show that we're bigger than the sum of our
parts. Do you get me? Imagine that tomorrow a gaggle of us projects
- some competitive, some cooperative - managed to reach a rough
agreement on some common technical standard (it doesn't matter what,
it could be quite trivial). Just the fact of it, the signal it would
send - you understand the significance - it would take us to a new
level.
Is it too early? You see how simple a transparency framework I
proposed in that thread - just some RDF and scripts. But you also see
what I'm up against - a wall of head-butting competitors, each looking
out for their own turf, and intent on ruling the world.
David Janes
Re context: Is it too early to start thinking about the framework for
developing those public APIs? It's not a technical question, at this
point. It goes beyond any specific relations between Shamen and
Votorola, too. I'm guessing it's more a question of transparency - of
having an open and trustworthy process of standards development. My
thinking is explained here:
http://metagovernment.org/pipermail/start_metagovernment.org/2009-February/thread.html#1189
GoogleVotes monopoly vs. JoeVotes ecosystem
The reason why I think it's *not* too early, is because it would be a
huge boost for all of us change projects, if we had a way to come
together (technically), and show that we're bigger than the sum of our
parts. Do you get me? Imagine that tomorrow a gaggle of us projects
- some competitive, some cooperative - managed to reach a rough
agreement on some common technical standard (it doesn't matter what,
it could be quite trivial). Just the fact of it, the signal it would
send - you understand the significance - it would take us to a new
level.
Is it too early? You see how simple a transparency framework I
proposed in that thread - just some RDF and scripts. But you also see
what I'm up against - a wall of head-butting competitors, each looking
out for their own turf, and intent on ruling the world.
There's a real danger of premature optimization here, of specifying standards before the problem is really understood. However, here is a stab at how I've seen successful APIs and data sharing develop on the web in the mashup world.
The core "frameworks" are POSH, REST and JSON. POSH [1] is "Plain Old Semantic HTML", meaning websites should be developed using modern web standards, pages should valid, pages use HTML elements correctly and presentation is coded using CSS. REST [2] can have deeper implications, but amongst the simplest implications is that pages can be returned using simple GET statements against a URL. JSON [3] has emerged as the defacto standard for returning API results, amogst the reasons for is simplicity of creating mashups and embeddability.
Atom and/or RSS provide the framework for update notifications. There are emerging technologies for real-time delivery, but it's too early to worry about that.
Microformats [4] provide a framework for embedding well-understood objects in HTML, are based on popular and well-understood standards, are easy(-ish) to implement, and a "consumer" ecosystem exists. In particular, people can be represented by hCard [5], events by hCalendar [6], tagged data by rel-tag [7] and microcontent (articles within a page) by hAtom [8]. Note that no "parallel" infrastructure need exist to do microformats: they are served within HTML pages.
Identify should use OAuth [9] and OpenID [10]; pragmatism says Facebook Connect and Google Friend Connect should be in the mix too, though I have a number of reservations about those.
I am very non-bullish about RDF [11]. IMHO it has missed almost the entirely the mashup wave of the last few years, and successes seem to be scattered at best. RDFa is competing in microformat's "space" and may see success yet if it starts proving concrete solutions rather than "here's a format that can do anything".
Regards, etc...
[1] http://en.wikipedia.org/wiki/Plain_Old_Semantic_HTML
[2] http://en.wikipedia.org/wiki/REST
[3] http://www.json.org/
[4] http://microformats.org/
[5] http://microformats.org/wiki/hCard
[6] http://microformats.org/wiki/hCalendar
[7] http://microformats.org/wiki/rel-tag
[8] http://microformats.org/wiki/hAtom
[9] http://oauth.net/
[10] http://openid.net/
[11] http://en.wikipedia.org/wiki/Resource_Description_Framework
[12] http://www.w3.org/TR/xhtml-rdfa-primer/
--
David Janes
Mercenary Programmer
http://code.davidjanes.com
Jennifer Bell
'machine readable API' and make the policy forward compatable? The
best technology solution(s) will depend on the application. Sites
that want to use the data can adapt easily enough.
For reference, at VisibleGovernment.ca we've been kicking around
technology constraints for software we fund. The most recent version
is:
* Software developed with VisibleGovernment.ca grants must be
released under an open source liscense. The MIT liscense is
preferred.
* Non-user related data must be exposed via machine readable
APIs.
* Sites requiring a user login must support OpenID.
* Sites requiring a friend list should use OpenSocial.
Also, there is a requirement to cross-promote VisibleGovernment.ca,
and other funded sites, during seasonal drives.
Comments welcome.
Jennifer
http://visiblegovernment.ca
David Janes
Instead of worrying about JSON vs. XML vs. RDL, why not just say
'machine readable API' and make the policy forward compatable? The
best technology solution(s) will depend on the application. Sites
that want to use the data can adapt easily enough.
I don't think that can be stressed enough that producing standards compliant, accessible, semantic HTML delivered via HTTP GET is the first step in web openness.
Michael Allan
Just for a concrete example, to show that I'm not so much concerned
with standards of transparency, but the reverse - transparency of
standards:
1. Project Votorola has an idea for a public standard S (for
storage/transmission of social data, or whatever). So we use the
transparency facility to say, "Hello, here is standard S!
Votorola will support S."
2. Project Shamen learns of S through the transparency facility
(transparent, because it makes S visible). They think S could be
useful, so they say, "Shamen will support S." (Meanwhile, the
two projects are talking together, and making improvements to S.)
3. Other projects learn that both Votorola and Shamen have agreed
(tentatively) to S. So they're thinking about it, too. They
each decide for themselves, and they say, "we will/will not
support S."
And so on, for all the people, projects, firms, organizations,
etc., and all the standards they propose.
That's it - just transparency. (But that's everything, IMHO.)
David Janes wrote:
> There's a real danger of premature optimization here, of specifying
> standards before the problem is really understood...
It's possible, the domain might get hide-bound from premature
standardization. (Mind, that's always a problem, even in a mature
domain.)
Then again, if we have a standards process that's transparent, maybe
it'll be proof against rigidity? I mean, engineers are always coming
up with ideas on how to escape from constraints - pushing the envelope
- right? So there's always grassroots initiative from that side. But
it's rarely made *visible* in public. Usually it's only the
organizations (like standards consortia) that have a sufficient public
presence. But they have a different dynamic, and often a different
motivation. And often (but not always), it's *they* who are
hide-bound.
> ... However, here is a stab
> at how I've seen successful APIs and data sharing develop on the web in the
> mashup world.
>
(Interesting. I'm just learning RDF. I'll look at Microformats,
before I commit to it.)
Maybe Microformats is an exception, but the rest are mostly
general-purpose standards. As such, they'll definitely be in the
"foundation mix" of whatever specialized standards emerge in the
political domain.
But it's that emergence - the seeding and growth process - that I want
to spotlight. In the case of the above standards, it was shrouded in
darkness. (Otherwise, maybe the ridiculousness of SOAP wouldn't have
been foisted on us. Maybe we'd have chosen REST, right from the
start. If only we knew that a choice was being called for - if only
there was sufficient transparency.)
Jennifer Bell wrote:
> Instead of worrying about JSON vs. XML vs. RDL, why not just say
> 'machine readable API' and make the policy forward compatable? The
> best technology solution(s) will depend on the application. Sites
> that want to use the data can adapt easily enough.
>
> For reference, at VisibleGovernment.ca we've been kicking around
> technology constraints for software we fund. The most recent version
> is:
>
> * Software developed with VisibleGovernment.ca grants must be
> released under an open source liscense. The MIT liscense is
> preferred.
> * Non-user related data must be exposed via machine readable
> APIs.
> * Sites requiring a user login must support OpenID.
> * Sites requiring a friend list should use OpenSocial.
>
> Also, there is a requirement to cross-promote VisibleGovernment.ca,
> and other funded sites, during seasonal drives.
I'll leave out the last item (cross-promo), because it's a contractual
obligation between two parties. What's left is a kind of umbrella, or
composite, standard. Call it U. It requires:
* compliance with certain other standards, namely ...
* following additional practices, namely ...
Now, assume we already have a transparent process of standards
proposal. Then your own change project (VisibleGovernment.ca) could
use it to propose U as a standard, and make it visible to the other
projects. You'd then learn which of them was, in principle, happy
with it. Would that information be useful to you?
On the other hand, would U's visibility be useful to the other
projects? I guess they'd learn what it takes to obtain a Seal of
Approval from VisibleGovernment.ca. (That sounds useful.)
If we just let in a little light, the changes will grow. No? Or is
it too early?
interfaced
This discussion is good, some very valid points that should be kept in
mind moving forward(formats, process, public face)
I don't want to get off track with actually getting some people
together in a room. Understandably this is difficult for some in other
places(Jennifer), but some people are quite close, and in-person is
more bandwidth.
Here's what I hear:
-Meet this week
-define clear share objectives & scenarios (postal code to edistrict,
edistrict to MP, ...)
-Form a couple small teams around core areas: UX, API(REST/GET),
Documentation(public facing explanation & promotion, ...)
-Commit to a process (weekly chat or wiki or another google group)
-Grab a pitcher(this one was an executive decision)
Thody
Based on the Doodle poll, I think Tuesday at 6pm looks good. Let's
meet here at 192 Spadina Ave, Suite 404 unless someone has a better
location in mind.
interfaced
is speaking...
http://www.360series.com/
Also, I could book a room here at the CSI if we could do it later. Or,
you guys could just meet and take notes. Either works!
Thody
Application Development" lecture until 5:30, so I'm not against a
little padding time.
Does moving it back to 8 work?
On Feb 23, 3:47 pm, interfaced <interfa...@gmail.com> wrote:
> I can't make tomorrow, just realized alex steffen from world changing
Michael Allan
> This discussion is good, some very valid points that should be kept in
> mind moving forward(formats, process, public face)
Patrick Keenan, I'm hearing it's not a topic you want to discuss.
You'd rather discuss the Shamen meeting. :)
Technically, this subthread isn't concerned with the Shamen meeting.
It's concerned with interproject transparency. You need to switch
your mail reader to "threaded view". (Or I need to stop branching
subthreads on people.)
> I don't want to get off track with actually getting some people
> together in a room. Understandably this is difficult for some in other
> places(Jennifer), but some people are quite close, and in-person is
> more bandwidth.
You guys have so much enthusiasm and energy, I think you should
schedule *two* meetings. Schedule the 1st at any reasonable time.
Let those who can't attend schedule the 2nd. I bet you'll get a good
turnout at both.
Tania Samsonova
>
> - Show quoted text -
Thody
Patrick can join us a little late (notes will be taken).
On Feb 23, 10:14 pm, Tania Samsonova <tania.samson...@gmail.com>
wrote:
Michael Allan
It's 19:40. Tania and other attendees are at the front door of 190
Spadina, and nobody's answering their ring.
Michael Allan
Tania, Adam say's it's 192 Spadina, and you ring 414. - M
Tania Samsonova
Internet access at the moment :-) I only saw your message when I got
home. Thanks for your help anyway.
OK, better luck next time. Maybe whoever organizes the meeting should
post their contact info.
Tania Samsonova
address. Ringing 404 as per Adam's earlier message. Maybe meeting
organizers should also double-check the meeting address they post.
Michael Allan
> Thanks Michael, but I called you exactly because I did not have
> Internet access at the moment :-) I only saw your message when I got
> home. Thanks for your help anyway.
I'm sorry you missed the meeting! When I relayed your message through
the list, I was so amazed that it *actually* reached Adam, I figured
it might work in the reverse direction. No such luck. :-(
> OK, better luck next time. Maybe whoever organizes the meeting should
> post their contact info.
Their big mistake was allowing me to crash this announcement
thread. ;) People got the impression that I was going to attend the
meeting, and talk about the "transparency of inter-project standards".
It had a negative effect on attendance. Almost nobody showed up.
Then you rang the buzzer. Adam and Patrick thought for sure it was
me, so they just ignored it. That's why you couldn't get in.
Then you sent Adam that relay message, reaching him via telephone ->
me -> the list -> other miraculous helpers... When Adam received this
message, he figured it could only be a ploy of mine, to gain entry.
So he decided to play along with me. He called me up and asked for
your number. But I didn't know your number, because I had neglected
to ask you for it! That was the clincher. It confirmed his
suspicions: I was downstairs, ringing the buzzer, and pretending to be
you. So he shut the blinds and carried on with the meeting. You
eventually gave up waiting, and went home.
So the organizers weren't to blame. It was mostly my fault,