Working Group Minutes/EWG 2012-11-12

Attendees

IRC nick	Real name
apmon_	Kai Krueger
pnorman	Paul Norman
ppawel	Paweł Paprota
RichardF	Richard Fairhurst
TomH	Tom Hughes
shaunmcdonald	Shaun McDonald
zere	Matt Amos
Summary

Notes/bugs branch:
- There are several unresolved issues holding up development of this feature:
  - whether anononymous (not logged-in) users should be supported
  - how to turn visibility of the notes/bugs on and off
  - whether the (denormalised) location hint field is wanted
- AGREED: notes viewing toggle should be in the layer switcher, with reporting via a "Report a problem" link in the exact same place that it is commonly found on other map sites.
- AGREED: drop the location field from the notes database, and look it up / cache it on-the-fly from Nominatim.
- ACTION: apmon to take the "anon notes" question to $MAILING_LIST
IRC Log

18:04:05 <zere> #startmeeting
18:04:05 <ewg-meetbot> Meeting started Mon Nov 12 18:04:05 2012 UTC.  The chair is zere. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:04:05 <ewg-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:04:48 <zere> minutes of the last meeting: http://www.osmfoundation.org/wiki/Working_Group_Minutes/EWG_2012-11-05 which i sadly haven't finished putting up yet, but will finish soon.
18:04:59 <zere> #topic Matters arising
18:05:38 <zere> we didn't have any new actions last meeting, but do we have any updates on previous actions?
18:05:56 <zere> i haven't had a response from LWG on the anonymous notes thing
18:06:10 <apmon_> What were the previous actions?
18:06:43 <TomH> LWG are still on hiatus aren't they?
18:07:04 <zere> the only other open one is whether ppawel did any more research into help.osm.org potential migrations.
18:07:23 <zere> yeah, i think they're taking a holiday, so i'm not massively surprised they've not replied
18:08:08 <apmon_> Is that something that is blocking merging the notes branch? Or just something that should be clarified for the future?
18:09:31 <zere> i thought whether we had an idea of whether the notes should be allowed to be anonymously entered was a pretty big deal, no?
18:09:46 <ppawel> there is no change with help.osm.org
18:09:58 <apmon_> It would be nice to have a (fairly) concrete list of tasks that still need to be done before it can be merged and deployed
18:10:28 <TomH> well I need to sort out anon notes
18:10:38 <TomH> and probably port to leaflet once we merge that
18:10:57 <apmon_> Do you want to do the leaflet merge first?
18:11:45 <TomH> oh I'm sure that will happen first - it's prtty much ready isn't it?
18:12:24 <apmon_> I just don't want to notes branch deployment drag on for more months (or years)...
18:13:01 <TomH> yes but basic physics applies - one is ready and the other isn't
18:13:15 <apmon_> It is an important feature to keep the OSM data current and of high quality. Pinch and Zoom for mobiles imho isn't
18:13:23 <TomH> we need to sort out anon users
18:13:30 <TomH> we need to sort out how to turn it on and off
18:13:42 <TomH> we need to sort out the location field - whether we want it etc
18:13:57 <RichardF> apmon_: I don't think you can really compare the two in terms of importance
18:13:59 <ppawel> +1 on the (written down) task list so that it's easy to jump in and help out
18:14:00 <TomH> so there is work to do on notes which depends on SOMEBOD MAKING POLICY DECISIONS
18:14:20 <TomH> much of this I summarised in my mail when I pushed the branch out
18:14:30 <TomH> so there is a to do list there AFAIK
18:14:41 <apmon_> TomH: Could you list those policy issues in a mail to OSMF-talk. That is probably the place to make those decisions
18:14:57 <TomH> WTF would I want to take them to that hell hole
18:15:10 <ppawel> btw there was an interesting suggestion on github to use IP addresses as anon usernames
18:15:15 <TomH> only the anon user thing has any business being there
18:15:20 <ppawel> I'd +1 that, seems to work for wikipedia
18:15:22 <zere> i think we should try to whittle down the list here, to avoid burdening osmf-talk with technical details
18:15:33 <TomH> I don't know how wikipedia gets away with that
18:15:46 <TomH> especially in eg germany where as I uderstand it they are very clear that IPs are personal data
18:15:54 <zere> TomH: what about "how to turn it on and off" needs to be sorted out, the mechanism for it? the user interface for it?
18:16:16 <ppawel> IP is personal?!?! geez...
18:16:33 <ppawel> is there no accountability anymore?... anyway, not the place to talk about it here...
18:16:38 <apmon_> ppawel: Yes, because it can be used to identify a user
18:16:40 <TomH> zere: yes UI - currently turned on from edit menu ( well hidden) and no way to turn off
18:16:59 <ppawel> apmon_, well people SHOULD be identifiable on the internet...
18:17:06 <ppawel> if they author some data or stuff
18:17:09 <zere> personally, i think it should be in the layer switcher - do we have a way to do that?
18:17:44 <ppawel> imho layer switcher would not expose this feature enough - maybe a new tab?
18:17:50 <ppawel> or option in the edit tab?
18:18:14 <zere> that's where TomH says it is already (bar the ability to turn it off...)
18:18:19 <apmon_> ppawel: If it is on by default (for new users) I think it would sufficiently expose it
18:18:47 <ppawel> http://notes.apis.dev.openstreetmap.org/ <- it's in the bottom right corner
18:19:18 <apmon_> I liked the suggestion for the UI for the "Data browser" in the layer switcher
18:19:30 <zere> ah, there's also "browse notes" in the drop-down edit tab
18:20:07 <apmon_> basically have a "+ notes" and "+ map data" in the layer switcher
18:20:07 <ppawel> but should browsing notes be restricted to the same zoom levels as editing?
18:21:22 <zere> for practical reasons i suspect it will have to be - otherwise there won't be sufficient accuracy in the placement, or there'll be too many results to be usefully visible
18:22:27 <zere> apmon_: i agree.
18:22:27 <apmon_> Perhaps there should be a difference between viewing and adding notes in that case. Just looking to see what Notes there are in an area does not suffer of placement accuracy
18:23:10 <zere> how do we resolve this? there seem to be two options on the table: add to layer switcher, or add as a new tab
18:23:37 <zere> is it worth taking a quick poll to see which is preferred?
18:24:01 <ppawel> I don't think this is a decision for _E_WG to make..
18:24:20 <ppawel> maybe saman (designer from mapbox) could come up with something
18:24:54 <ppawel> but I'm not sure if this single issue should hold back rolling out notes...
18:25:00 <zere> sadly, he's not here, but i'm sure if he came up with something then that would at least help frame the discussion
18:25:41 <zere> well, TomH said it's a sticking point at the moment, so i'd like to resolve it. it doesn't have to be perfect, just enough to move on with
18:26:57 <RichardF> +1 to apmon_ "difference between viewing and adding notes"
18:27:39 <RichardF> I'd suggest - viewing in the layer switcher (as per zere), adding via a "Report a problem" link in the exact same place that Google has its link :)
18:28:06 <apmon_> +1 to that
18:28:16 <zere> +1 also
18:29:08 <zere> are we agreed on that? at least to move forward - it's not set in stone and i'm sure saman's input would be very welcome
18:29:23 <ppawel> sounds good but I can't find report a problem on google maps :)
18:29:38 <ppawel> ah ok I see it now
18:30:06 <zere> haha - maybe it's not such a good UI then ;-)
18:30:23 <ppawel> just needed to zoom in from world zoom level to continent zoom level
18:30:57 <zere> #agreed notes viewing in the layer switcher (as per zere), adding via a "Report a problem" link in the exact same place that $OTHER_MAP_SITE has its link
18:31:02 <ppawel> btw I like what happens when you click that link
18:31:10 <ppawel> but that's probably for notes 2.0 :)
18:31:40 <zere> the next issue is this "location field" - TomH, what needs sorting out there?
18:32:55 <zere> ppawel: absolutely. as soon as this is merged and visible on the site it will start to generate real feedback that can be used to really improve it.
18:33:18 <apmon_> If you look at e.g. http://notes.apis.dev.openstreetmap.org/api/0.6/notes/5 It has a "near by" field that is the output of nominatim of the position of the note
18:33:42 <apmon_> I guess the question is: does that make sense, or should it be dropped?
18:34:26 <zere> you mean, because we have the lat/lon, is it worth including that output when a client could go to nominatim itself if it wanted that?
18:34:35 <zere> i assume it's not actually stored in the database?
18:34:40 <apmon_> It is ;-)
18:35:07 <zere> ah, well i don't see the need for that. presumably if someone updated the nearby data we'd want that reflected
18:35:51 <apmon_> Should it only be dropped from the database, or also from the output?
18:36:59 <zere> personally, i don't see the point if the lat/lon is already there... but maybe i'm missing some use of this thing?
18:37:11 <apmon_> I can write a patch to drop that functionality, then.
18:37:48 <zere> i'm imagining people looking at the map with notes on it, and from that point of view, they'd already be "spatially oriented" by the map itself
18:38:05 <zere> is there another use of that data where the map wouldn't be present, or wouldn't be useful for orienting the user?
18:38:05 <apmon_> It might be useful in the RSS feed
18:38:47 <zere> are RSS feeds available by location / bbox?
18:38:59 <apmon_> They should be
18:39:10 <apmon_> The other area would be in http://notes.apis.dev.openstreetmap.org/user/apmon-test/notes
18:40:22 <apmon_> At least there used to be an rss feed, but I currently don't know what the URL for those are
18:40:59 <zere> i suppose if it's useful for a browser view, then it's possible that it could be fetched by the browser-side JS
18:41:38 <apmon_> Yes, that is reasonable. And the load is presumably not high enough for caching to be necessary
18:41:59 <apmon_> Or at least no more than having to cache the page in the first place
18:42:24 <zere> on the whole, i'm definitely against storing it in the database. i don't feel particularly strongly about including it in the output. if the lack of caching is a problem, we can always stick some memcached in there.
18:42:56 <apmon_> TomH: Are you OK with that? To drop the location field?
18:43:14 <zere> would anyone else like to comment on this?
18:43:48 <TomH> apmon_: Sure, anything that simplifies things
18:44:20 <apmon_> OK, I'll come up with a patch to remove that stuff then.
18:44:33 <TomH> zere: we do cache the reverse lookup in otehr places
18:44:42 <zere> #agreed drop the location field from the notes database
18:44:45 <zere> TomH: cool
18:45:05 <zere> #topic top ten tasks
18:45:16 <zere> i'm looking at the TTTs (http://wiki.openstreetmap.org/wiki/Top_Ten_Tasks)
18:45:51 <zere> and there are 7 of these left, of which 2 are under active development, the others not quite so much
18:45:57 <apmon_> Depending on if you put vector tiles into the "clickable POI" task, but I have made some progress on those
18:47:08 <apmon_> I have a demonstration page up and running providing json tiles through the standard mod_tile / tirex (cover backend)/ osm2pgsql stack.
18:47:16 <zere> apmon_: sadly not. vector tiles is pretty exciting, but i'm not sure it's a solution to clickable for a large fraction of browsers today...
18:47:45 <apmon_> Overall it seems pretty feasible
18:47:56 <ppawel> url?
18:48:17 <apmon_> http://toolserver.org/~osm/styles/kothicJS.html
18:48:36 <apmon_> Unfortunately the server has lost its NFS mount currently, so it won't work until that is fixed
18:49:03 <ppawel> ok
18:49:06 <ppawel> (btw, also: XMLHttpRequest cannot load http://a.www.toolserver.org/tiles/vtile/1/1/1.js. Origin http://toolserver.org is not allowed by Access-Control-Allow-Origin.)
18:49:23 <zere> i think it might be closer to the "POI inspection tool", than "clickable POIs". when we split those tasks, the "clickable" part was explicitly tied to the rendering, and i don't see us switching the main style to pure vector any time soon.
18:49:35 <apmon_> It will work, once the NFS mount is back up, as mod_tile now supports CORS
18:49:46 <ppawel> ok cool
18:50:44 <apmon_> But we could offer vector rendering as an additional style
18:50:56 <zere> apmon_: yes, that would be awesome
18:51:34 <zere> the question is: if we consider 3 of the 7 to be under active development, what can we do to try and kickstart the other 4?
18:51:42 <apmon_> And I guess the current tile server would have the capacity to support that. But I still need to get a better feel for the resource requirements for that
18:51:49 <zere> are they just too boring? too difficult?
18:52:27 <apmon_> Which ones are not under active development?
18:52:40 <apmon_> For some definition of active?
18:52:51 <ppawel> isn't 1 (notes) active as well?
18:53:19 <zere> help.osm.org i18n, clickable (rendering-dependent) POIs, routing frontend, deleted items API call
18:53:46 <apmon_> I can get back onto working on the routing frontend as soon as the notes branch is merged and deployed
18:53:55 <zere> i'm making the assumption that if i haven't heard anything on these in the last couple of weeks then they're effectively inactive at the moment.
18:54:15 <zere> apmon_: excellent - glad we made some progress on that today
18:54:28 <apmon_> but serializing the front page development imho makes more sense
18:54:52 <apmon_> otherwise  you have to many merge conflicts like e.g. with the leaflet patch
18:55:10 <zere> oops, i forgot that last item - anyone want to take the "anon notes" question to osmf-talk and report back what (if any) consensus there is?
18:55:12 <apmon_> which will "break" both the notes and routing front end patches
18:56:07 <zere> sure, but apart from the routing frontend, most of the other tasks aren't bound by rails_port work as far as i can see...
18:56:11 <ppawel> well help.osm.org thing looks feasible, a bit boring I guess.. I got occupied with other stuff (OWL), to be honest I don't see myself going beyond finishing research - unless there's some other "motivation" like a contract; if it's on volunteer basis I have other fish to fry :)
18:56:24 <shaunmcdonald> I'm thinking that one of the urls in the API response should go to the html page of http://notes.apis.dev.openstreetmap.org/browse/note/5 Similarly the popup should have a link to go there too. The allowing users to link to a specific note easily.
18:57:45 * shaunmcdonald forgot about the meeting and has just caught up with the log
18:59:39 <apmon_> Btw: any comments on https://github.com/openstreetmap/openstreetmap-website/pull/153 ?
18:59:43 <zere> perhaps it's better to come back to this next week, but the EWG budget does include provision for "bounties", which we could use to promote the completion of these tasks.
19:01:12 <TomH> apmon_: well you know my opinion ;-)
19:01:22 <ppawel> zere, I'd be *very* interested in working on a bounty basis, or at least discussing this topic
19:02:08 <apmon_> TomH: It is so little code, that it is imho worth it as an interim solution
19:02:58 <TomH> apmon_: yeah, except it seems to have grown to about four times the size of that "little" code you originally showed ;-)
19:03:11 <zere> apmon_: it seems to require registering OSM as a facebook / MS live "app"
19:03:16 <TomH> with a lot of what looks like cut and paster work
19:03:21 <TomH> zere: yes it does
19:03:23 <ppawel> oh my, user controller seems to be ready to take over the world
19:03:39 <TomH> which is why I never enabled faceboo logins on help.osm.org because it wasn't clear who should do that
19:03:51 <apmon_> TomH: most of that is cut and past to clean up things and unify them with the openID. I.e cleanup work
19:04:11 <zere> TomH: s/who/whether/
19:04:35 <apmon_> zere: What is wrong with giving people options?
19:04:51 <zere> is that what all the "login with facebook" things do - they all use oauth hackery beneath the surface? yuck...
19:05:31 <zere> apmon_: nothing, but getting a facebook app id might require "signing" some stuff with facebook w.r.t user data, so it's not exactly straightforward
19:05:46 <zere> is there any reason why they aren't doing things the proper (openid) way?
19:06:24 <TomH> apmon_: it was more the cut and paste duplication of facebook stuff to ms live stuff
19:06:31 <ppawel> zere, walled garden?
19:06:38 <TomH> and does anybody actually use ms live!?!?!
19:06:45 <apmon_> I don't know. I'd much prefer them doing OpenID as well. But imho this is not the right place to go on a "crusade" for doing things the correct way.
19:06:46 <TomH> I've never noticed any site offering it
19:07:21 <apmon_> 900 Million people use facebook
19:08:02 <apmon_> TomH: Enable MS live login, and you can find out how many people use it ;-)
19:08:14 * pnorman waves
19:08:35 <ppawel> zere, btw I don't see how it requires an osm facebook app? looking at https://developers.facebook.com/docs/concepts/login/login-architecture/  it's just communication with facebook api?
19:09:19 <TomH> you need a token, which you get by registering an app
19:09:23 <ppawel> ah ok, here it is.. https://developers.facebook.com/docs/howtos/login/server-side-login/
19:09:30 <zere> ppawel: i was just going by https://github.com/apmon/openstreetmap-website/commit/33a226ddb1c94273f7ade32936f2011f26f97264#L6R77 where it mentions facebook_app_id and facebook_app_shared_secret
19:09:42 <ppawel> yes ok, sorry for the noise
19:10:37 <apmon_> TomH: slightly outdated, but might be interesting: http://mashable.com/2010/04/07/google-facebook-sign-in/
19:13:01 <ppawel> definite +1 for this feature (at least facebook) from me. not sure yet about the code (looks a bit like reinventing the wheel? aren't there libraries that do that magically?) and privacy questions (what zere said)
19:13:59 <apmon_> Privacy wise, it is optional. So if you don't want to use it there is no negative consequence.
19:14:35 <apmon_> And library wise. Yes, there are libraries, but that would require a complete rewrite of the authentication subsystem, where as that patch exists and works!
19:14:36 <ppawel> yeah but I meant more about the facebook app/token stuff which is used for the whole process
19:15:23 <apmon_> ppawel: Can you give an example?
19:15:29 <zere> oh, i didn't mean privacy for facebook users - i meant there would be a "developer" relationship between someone on behalf of the OSM site and facebook, which would require signing facebook's terms and conditions
19:15:48 <zere> and who knows what batshit crazy nonsense they might have hidden in their terms?
19:18:21 <ppawel> apmon_, I meant what zere explained above - someone would need to create "official OSM" facebook account, agree to some TC's.. I think it's not a big problem but perhaps a blocker - who should do this? OSMF? some admin?
19:18:40 <zere> "Quality of content: you are responsible for providing users with a quality experience and must not ... surprise users" <-- what, not even a pleasant surprise?
19:19:01 * pnorman grumbles
19:19:30 <ppawel> apmon_, as for the complete rewrite - I'm not 100% sure that this rewrite would be much larger than your patch. just looking at http://blog.yangtheman.com/2012/02/09/facebook-connect-with-rails-omniauth-devise/
19:21:40 <TomH> well I'm sure it would be a big and invasive patch to switch to devise but I'd like to see it happen
19:21:59 <TomH> I'm happy to take apmon_'s patch for now subject to a bit of cleanup and working out the legal issues
19:22:31 <pnorman> I understand that the LWG is likely to be meeting relatively soon, they've had a few questions referred to them
19:23:51 <apmon_> OK, I'll try and see what the minimum terms and conditions someone would have to agree to to get a facebook app id
19:24:01 <zere> at a first glance, the FB T&Cs seem surprisingly sane, given sane interpretations of some specific words (i.e: 'friends' on OSM doesn't constitute a social network)
19:25:00 <zere> ok - last item:
19:25:32 <zere> is anyone willing to volunteer to take the "anon notes" thing to osmf-talk, and bring back whatever consensus there may be?
19:25:50 <pnorman> is osmf-talk@ the appropriate list?
19:26:14 <apmon_> zere: I can do that
19:26:17 <zere> well... who knows what the appropriate list is...
19:26:31 <zere> if it gets punted from osmf-talk then so be it
19:27:06 <pnorman> I've taken questions of that nature directly to the LWG - I suppose legal-talk@ would also work
19:27:14 <zere> i think it's important to figure out: are anon users important? if they are, what can we do to protect against the risk of data being misused?
19:27:45 <zere> it's gone to LWG as well, but i don't think we necessarily need to restrict ourselves to that
19:28:10 <zere> #action apmon to take the "anon notes" question to $MAILING_LIST
19:29:03 <ppawel> perhaps OSM could learn from Wikipedia on the anon users/IP addresses issue.. I bet they asked themselves the same questions at some point (in the distant past)
19:29:32 <TomH> not really, they're americans so it won't have crossed their minds
19:29:51 <apmon_> It has already been discussed at least on the rails-port list and talk-de, so OSMF-talk seems appropriate for finding a decision.
19:30:00 <zere> OSM used to have anon users, but the feature was disabled
19:30:09 <zere> s/feature/bug/ perhaps ;-)
19:30:45 <zere> ok, we've overrun significantly - thanks to everyone for coming
19:30:47 <zere> #endmeeting