Working Group Minutes/EWG 2014-03-10

From OpenStreetMap Foundation


IRC nick Real name
gravitystorm Andy Allan
pnorman Paul Norman
RichardF Richard Fairhurst
TomH Tom Hughes
zere Matt Amos


  • DST switches
    • USA switched to DST between this meeting and the last. EU won't switch until the end of March.
    • No plans to change the time of the meeting (i.e: still 17:30 GMT), but it can be changed if anyone is inconvenienced post-DST switches.
  • Routing
    • Outstanding issues:
      • sending the right locales to the routing services (apmon may be looking at this)
      • providing permalinks (though I think we decided that this wasn't a blocker for v1)
      • design issues as per Saman
    • Permalinks / client-side routing (URL-routing, not navigation-routing) needs to be fixed as it's currently the way that the client stores state, or something?
    • HTTPS: need to exclude HTTP-only routing services to avoid "mixed content" warnings.
  • EWG effectiveness
    • gravitystorm was looking for some help analysing contribution rates (e.g: [1]) to see whether there are any lessons we can learn.
    • The ohloh graphs seem incorrect - but can get the same information from git logs.


17:35:02 <zere> minutes of the last meeting: please let me know if anything needs changing
17:36:15 <zere> i don't have anything for the agenda, and there aren't any open actions on anyone who's here
17:36:31 <zere> so the floor is wide open: anyone have anything they'd like to discuss?
17:36:32 <pnorman> administrative item: we had DST switch in the US
17:36:55 <RichardF> worth following up anything from the hack weekend?
17:37:35 <zere> yup, thanks pnorman. the 17:30 GMT time won't change unless we decide it should - in other words, we don't correct for anyone's DST automatically.
17:37:53 <pnorman> I'm busy working away on osm2pgsql benchmarking. I think in theory we've got the new release ready, just missing a couple of index statements at the start so performance is currently shite, but results check out
17:37:55 <zere> but if the "new time" proves a hassle, please feel free to bring up a change of time.
17:38:12 * pnorman prefers this time, because he's actually awake
17:39:01 <zere> well... the actual time hasn't changed ;-)
17:39:41 <zere> RichardF: sure - i think you're close to having routing merged? any help you'd like with anything outstanding on that?
17:41:41 <RichardF> there's three things mentioned in the pull request:
17:41:55 <RichardF> - sending the right locales to the routing services (apmon may be looking at this)
17:42:19 <RichardF> - providing permalinks (though I think we decided in the pub on Saturday that this wasn't a blocker for v1)
17:42:24 <RichardF> - design issues as per Saman
17:42:46 <RichardF> but generally I think it's ready to go other than anything TomH might want to do to whip it into shape :)
17:44:54 <TomH> do all the backends support https, and do we use it when we were loaded over https?
17:45:40 <TomH> RichardF: I don't see how you can integrate it into the client side routing without permalinks, and if that isn't done then it's not mergeable as far as I'm concerned
17:46:24 <RichardF> (a) don't know, (b) ok, but that's _way_ outside my knowledge zone so others'll need to look at that
17:47:47 <zere> all the state of the UI now needs to have a permalink?
17:49:12 <TomH> well I guess it would work without, and even preserve state correctly on forward/back for modern browser, but a reload would lose state which isn't ideal
17:49:47 <zere> i suppose it must be the new Rails way.
17:49:48 <TomH> but yes, everything else which doesn't work by loading a URL from the server preserves state properly client side
17:50:02 <RichardF> (quick experiment - MQ appears to offer HTTPS though we don't currently ask for it, and don't)
17:50:14 <TomH> not rails, it's stuff jfire wrote - see the big comment in router.js
17:50:56 <TomH> well that gives us a problem then as routing will fail if we were loaded over https unless we call the routing engine over https
17:51:06 <TomH> at least in modern browser than block active mixed content
17:51:41 <zere> so each backend needs a flag to filter it out when the site is in https.
17:52:03 <zere> so each backend needs a flag to say whether or not to filter it out when the site is in https.
17:52:55 <RichardF> that's doable. does mean anyone who views the site as https will only get Mapquest, but their choice.
17:53:06 <RichardF> (not that there's anything wrong with MQ, he says hastily :) )
17:53:44 <zere> i suspect others will offer https at some point, but i don't think we should wait for that
17:53:49 <RichardF> yep
17:54:11 <zere> or indulge requests to add special-purpose, or small-scale routing engines, as mentioned on the PR comments.
17:54:56 <zere> as they say, these are "Version 2" features.
17:55:16 <TomH> Version 200 more like
17:55:51 <zere> well, whatever. but it's a "perfect is the enemy of good enough" situation.
17:56:21 <TomH> oh sure, there is no question that we shouldn't be adding more features at this point
17:57:23 <TomH> but the current plan is quite scary enough for me - the idea of adding lots more engines at some point in the future is just a nightmare
17:58:06 <RichardF> it's half a nightmare, if that makes it easier ;)
17:58:22 <RichardF> I strongly suspect that most routers will be instances of OSRM or Graphhopper
17:58:30 <RichardF> so you still have the availability issue, but not the code issue
17:58:58 <RichardF> but, well, it's up to us to what we accept, so we can say "sorry, suspected nightmare, no thanks"
18:02:37 <zere> yup. it should be the same as the tile layer list; people are welcome to propose anything which meets the minimum criteria, but OWG will have to make a final determination of whether it's feasible, worthwhile and adds more value than the problems it creates.
18:03:06 * RichardF nods
18:03:56 <RichardF> "Don't show http-only routers to users on https"
18:05:05 <zere> RichardF: nice :-)
18:05:42 <gravitystorm> (I have another topic, as and when we get there)
18:05:44 <zere> so the last remaining issue is about the UI / client-side routing / permalink
18:06:04 <zere> anyone feel like volunteering to help RichardF with it?
18:07:41 <RichardF> don't all shout at once :)
18:08:25 <gravitystorm> RichardF: I can change my passive not-volunteering into an active not-volunteering, if that helps :-)
18:09:32 <RichardF> \o/ oh, wait
18:11:02 <zere> yeah, i keep meaning to abuse^W learn some javascript.
18:11:52 <zere> unless there's a sudden flood of volunteers... let's move on to gravitystorm's topic
18:12:10 <zere> gravitystorm's *mysterious* and unknown topic...
18:13:11 <gravitystorm> So my topic is measuring EWG effectiveness, more or less. But my question is more specific. Has anyone tried measuring stats on our "core" projects e.g. active contributors per month?
18:13:51 <gravitystorm> And as a related question, does anyone have any suggestions for tools that I can use on each git repo to produce useful progress metrics?
18:14:07 <pnorman> ohloh? github?
18:14:13 <pnorman> e.g.
18:14:21 <gravitystorm> The eventual outcome is that I can draw graphs and say "the number of contributors are rising" or not, as needs be
18:15:04 <gravitystorm> pnorman: yeah, I used that for my mapnik-stylesheets commits-over-time graph, but I'd prefer if I can find a tool to control the output a lot more
18:15:11 <zere>
18:15:37 <zere> "the number of contributors is spiky"
18:19:24 <gravitystorm> the number of contributors on is wrong
18:19:32 <gravitystorm> well, the graph is wrong I mean
18:19:54 <gravitystorm> anyway, if nobody knows of any tool, nor anyone else doing the analysis, then I'll do some
18:20:51 <pnorman> there's probably something out there - and isn't ohloh open to some degree?
18:21:33 <zere> well, if it's just number of unique contributors per month, then that's trivially easy to extract from `git log`.
18:27:48 <zere> gravitystorm: git log --format="%ai %ae" | awk '{print $1 " " $4;}' | sed "s/-[0-9][0-9] / /" | sort | uniq | awk '{print $1;}' | uniq -c
18:28:26 <zere> was there any other business anyone wanted to discuss?
18:29:07 <gravitystorm> not from me
18:33:05 <zere> ok. thanks to everyone for coming & see you next week :-)