Thanks to all who joined the call today. I've created a page on the wiki for
the notes: http://wiki.open311.org/Calls/2011-09
Here they are copied below
=Roll Call=
* Kevin Porter and Petar Lalovic from Toronto
* Michael Lawrence Evans from Code for America
* Mark Head from Voxeo Labs
* Cliff Ingham and Rick Dietz from Bloomington
* Matt Bonness from Motorola
* Eric Carson from Connected Bits
* Dmitry Kachaev ex-Dc.gov/OCTO Labs
* Philip Ashlock with OpenPlans & Civic Commons
=Review state of deployments=
Discuss adoption by providers and clients, this will help us understand the
need we may address with spec changes.
* Matt: Baltimore Service discovery URL is still blank.
* Eric: ConnectedBits will add these URLs. A couple more deployments coming
in the near future.
=GeoReport 2.x=
Review process of continued development of GeoReport v2 spec. Went over the
proposal outlined at
http://lists.open311.org/groups/discuss/messages/topic/6QwZRga9MPbkYOCqCYh9sU
=GeoReport features for future spec=
* User management - authentication. Need to filter for users own requests
** Cliff: may also have a mobile version without a "my reports" feature. No
clear path on approach (openid, oauth, have complexities).
** Mark: Authentication is the tricky part, once we have it, we can let
servers decide what to spit out. The server can decide what information to
return or accept based on the authentication.
** Possibly add list of permissions to discovery somehow.
** Would be good to use a standardized approach to authentication.
* Media handling, just add that as part of POST, eg as multipart.
* Cross domain handling with JS, eg JSONP.
* Adding internal management features to the spec (update status, assign
ticket, etc)
** complex issue, different workflow models, and permissions. We should be
cautious about going into this.
* Commenting. How to add additional information about an existing request.
Good to have a two way dialogue. In Bloomington, we anticipate multiple
requests for the same problem and those can be easily grouped.
* Petar on mandatory fields: Fields that we require, vs optional. How do we
convey that something defined as optional in the spec is actually mandatory
for us. Additional node in service definition response, list the arguments
for required fields that are part of the core spec. Example is graffiti on
private building, we require names and emails. Override using
service_definitions with their own requirements. This needs additional
discussion, continue the original thread:
http://lists.open311.org/groups/discuss/messages/topic/1Yj3jSrYVYjZYuAgpvpGxx
** Change the spec to be explicit about required fields, eg email,
locations.
* non-geospatial uses of GeoReport, eg federal level interest. This is
already being done in Bloomington
=Service Discovery=
* LoST as possible long term approach
* start with list, name of city and jurisdiction_ids
=Inquiry API development=
More to come. New wiki page for drafting:
http://wiki.open311.org/Inquiry_v2_Draft
=Inventory of Products/Services=
Please add yours: http://wiki.open311.org/GeoReport_v2/Support
=Additional Discussion=
* Dmitry: Question to CfA folks - new Dashboard, can it be easily connected
to other cities.?
* Michael: It works with Boston's data, but we might not be getting all
their data. It's not easily plugged in and there are inconsistent
implementations of the spec in different cities. Will be posting
documentation of issues that came up.
* Michael: Apigee, console for Twitter API.
* Phil: Mashery open sourced their interactive API docs. We can see about
implementing this for our docs: https://github.com/mashery/iodocs
* Dmitry: WMATA folks said Mashery offers some of their service to
government for free.
* Mark: Need to think about API platform services using open standards
* Phil: Validator should help on ensuring interoperability and consistent
implementations.
* Michael: a founder of github created a thing called http://hurl.it - easy
way to test APIs online so you don't have to know too much about it. Has
inspired twitter API interfaces, eg https://github.com/marcel/twurl
* Kevin: concern over privacy. If people come in to use these apps ... If
they come in through our website, we can put up a blurb, but if they come up
through via itunes, how do we tell them our privacy policy. Having a blurb
about privacy/policy for each jurisdiction - maybe as part of service
discovery, the spec does get into SLAs and things per request, but maybe a
need for some higher level language. Also a need to set expectations about
whether you're interacting with an official jurisdiction and who they are.
* Cliff: Also, possibly something at the service discovery level, a way to
indicate a logo or other graphics and content/design that might be specific
to the jurisdiction.
=Meta=
Notes originally taken at: http://etherplans.org/open311-2011-09
the notes: http://wiki.open311.org/Calls/2011-09
Here they are copied below
=Roll Call=
* Kevin Porter and Petar Lalovic from Toronto
* Michael Lawrence Evans from Code for America
* Mark Head from Voxeo Labs
* Cliff Ingham and Rick Dietz from Bloomington
* Matt Bonness from Motorola
* Eric Carson from Connected Bits
* Dmitry Kachaev ex-Dc.gov/OCTO Labs
* Philip Ashlock with OpenPlans & Civic Commons
=Review state of deployments=
Discuss adoption by providers and clients, this will help us understand the
need we may address with spec changes.
* Matt: Baltimore Service discovery URL is still blank.
* Eric: ConnectedBits will add these URLs. A couple more deployments coming
in the near future.
=GeoReport 2.x=
Review process of continued development of GeoReport v2 spec. Went over the
proposal outlined at
http://lists.open311.org/groups/discuss/messages/topic/6QwZRga9MPbkYOCqCYh9sU
=GeoReport features for future spec=
* User management - authentication. Need to filter for users own requests
** Cliff: may also have a mobile version without a "my reports" feature. No
clear path on approach (openid, oauth, have complexities).
** Mark: Authentication is the tricky part, once we have it, we can let
servers decide what to spit out. The server can decide what information to
return or accept based on the authentication.
** Possibly add list of permissions to discovery somehow.
** Would be good to use a standardized approach to authentication.
* Media handling, just add that as part of POST, eg as multipart.
* Cross domain handling with JS, eg JSONP.
* Adding internal management features to the spec (update status, assign
ticket, etc)
** complex issue, different workflow models, and permissions. We should be
cautious about going into this.
* Commenting. How to add additional information about an existing request.
Good to have a two way dialogue. In Bloomington, we anticipate multiple
requests for the same problem and those can be easily grouped.
* Petar on mandatory fields: Fields that we require, vs optional. How do we
convey that something defined as optional in the spec is actually mandatory
for us. Additional node in service definition response, list the arguments
for required fields that are part of the core spec. Example is graffiti on
private building, we require names and emails. Override using
service_definitions with their own requirements. This needs additional
discussion, continue the original thread:
http://lists.open311.org/groups/discuss/messages/topic/1Yj3jSrYVYjZYuAgpvpGxx
** Change the spec to be explicit about required fields, eg email,
locations.
* non-geospatial uses of GeoReport, eg federal level interest. This is
already being done in Bloomington
=Service Discovery=
* LoST as possible long term approach
* start with list, name of city and jurisdiction_ids
=Inquiry API development=
More to come. New wiki page for drafting:
http://wiki.open311.org/Inquiry_v2_Draft
=Inventory of Products/Services=
Please add yours: http://wiki.open311.org/GeoReport_v2/Support
=Additional Discussion=
* Dmitry: Question to CfA folks - new Dashboard, can it be easily connected
to other cities.?
* Michael: It works with Boston's data, but we might not be getting all
their data. It's not easily plugged in and there are inconsistent
implementations of the spec in different cities. Will be posting
documentation of issues that came up.
* Michael: Apigee, console for Twitter API.
* Phil: Mashery open sourced their interactive API docs. We can see about
implementing this for our docs: https://github.com/mashery/iodocs
* Dmitry: WMATA folks said Mashery offers some of their service to
government for free.
* Mark: Need to think about API platform services using open standards
* Phil: Validator should help on ensuring interoperability and consistent
implementations.
* Michael: a founder of github created a thing called http://hurl.it - easy
way to test APIs online so you don't have to know too much about it. Has
inspired twitter API interfaces, eg https://github.com/marcel/twurl
* Kevin: concern over privacy. If people come in to use these apps ... If
they come in through our website, we can put up a blurb, but if they come up
through via itunes, how do we tell them our privacy policy. Having a blurb
about privacy/policy for each jurisdiction - maybe as part of service
discovery, the spec does get into SLAs and things per request, but maybe a
need for some higher level language. Also a need to set expectations about
whether you're interacting with an official jurisdiction and who they are.
* Cliff: Also, possibly something at the service discovery level, a way to
indicate a logo or other graphics and content/design that might be specific
to the jurisdiction.
=Meta=
Notes originally taken at: http://etherplans.org/open311-2011-09