Working Group Minutes/EWG 2013-07-22

From OpenStreetMap Foundation


IRC nick Real name
apmon Kai Krueger
Firefishy Grant Slater
gravitystorm Andy Allan
lonvia Sarah Hoffmann
mvexel Martijn van Exel
pnorman Paul Norman
RichardF Richard Fairhurst
shaunmcdonald Shaun McDonald
tmcw Tom MacWright


  • openstreetmap-carto
    • Tiles from Orm now available (but not everywhere), needs some eyeballs to check for errors.
  • labelling issues on github projects
    • Question is whether labelling issues and PRs is useful, and whether assigning people specifically is useful. And whether, supposing it is, EWG should put effort into helping triage / label on OSM-related projects.
    • Opinions differ: Some people don't use labelling at all, others find it useful particularly for distinguishing "types" of issues.
  • publicity around moderately large updates to the website
    • Following on from some annoyance on the talk@ list about lack of visibility of upcoming changes to the site, it was suggested that notification of merges be sent to the talk@ list for discussion.
    • There seemed to be two sides to this discussion:
      • That it would be very difficult to get high quality, actionable feedback from talk@ threads, and that broad consensus would not be possible.
      • That including a wider audience would reduce the unexpectedness of changes, and potentially incorporate new testers and developers into the merge process.
    • There was no conclusion.


17:05:44 <gravitystorm> I have the following on the agenda:
17:05:59 <gravitystorm> * labelling issues on github projects
17:06:02 * mvexel says hi
17:06:20 <gravitystorm> * publicity around moderately large updates to the website
17:06:26 <gravitystorm> * openstreetmap-carto (as usual)
17:06:33 <gravitystorm> anything else?
17:07:15 <pnorman> management team meeting is tomorrow, so if we have anything we want to bring up then myself or andy could do so
17:07:42 <gravitystorm> good point, let's discuss that at the end
17:07:58 <gravitystorm> #topic openstreetmap-carto
17:08:29 <pnorman> grant is switching over the australia cache right about now
17:08:32 <gravitystorm> since it should be quick, let's do this first. There's no changes to the style itself, but I have word that orm is now serving live traffic to Oceana
17:08:58 <gravitystorm> we should get lots of eyeballs, and perhaps some more interest from cartographers
17:09:18 <gravitystorm> that's all I've got on this topic. Anything else that we should mention?
17:09:31 <pnorman> was orm imported with -G?
17:09:57 <gravitystorm> I've no idea
17:10:32 <pnorman> see for why it matters
17:10:42 <pnorman> well I guess I could just look at orm's tiles to tell
17:11:16 <pnorman> looks like it was
17:12:09 <pnorman> maybe. if it wasn't, we really need to reimport
17:12:49 <gravitystorm> Or it can be dealt with using SQL. Let's move on to more EWG-ish things
17:13:08 <gravitystorm> #topic labelling issues on github projects
17:13:18 <gravitystorm> pnorman: go for it :-)
17:13:45 <pnorman> picking on osm-website, the latest issue is #370, and #200 is the last one labeled.
17:14:36 <pnorman> to be fair, many other OSM-related repos also have most tickets unlabeled. it makes it way easier to know what tickets are of interest and to find tickets when you label them
17:15:20 <gravitystorm> tmcw: you deal with lots of github repos, I'd appreciate your thoughts on tagging the issues
17:16:31 <gravitystorm> is it useful? Does it attract developers? Is it just make-work? Should EWG be putting effort into helping projects, or just leaving them to do their own thing?
17:17:04 <tmcw> sorry one sec
17:17:50 <gravitystorm> no problem - everyone else feel free to chip in too!
17:19:57 <pnorman> I've found it useful with osm-carto to know what I care about and what I don't, since I'm not a cartographer
17:21:09 <pnorman> quiet bunch today :)
17:21:40 <gravitystorm> welcome apmon
17:22:49 <gravitystorm> Firefishy: lonvia: mvexel: RichardF: shaunmcdonald: TomH: it would be great to hear from you, even if it's just to say "I have no opinions on this matter" :-)
17:23:22 * Firefishy catching up.
17:24:29 <apmon> gravitystorm: Is there a log file to catch up on?
17:25:14 <gravitystorm> apmon: I'm not sure - probably need zere for that. I've PM'd you the current topic
17:25:23 <RichardF> I can give you a general impression on openstreetmap-carto but I'm not sure if it's helpful...?
17:25:42 <gravitystorm> RichardF: (18:13:08) gravitystorm: #topic labelling issues on github projects
17:25:47 <RichardF> github is way beyond my pay grade though :)
17:26:11 * lonvia never makes use of labeling in github
17:26:33 <gravitystorm> RichardF: well, you use github to manage the p2 issues. Do you tag the issues? Would it be helpful? Would it be helpful of EWG put effort towards tagging those issues?
17:26:46 <gravitystorm> lonvia: thanks
17:27:35 <apmon> found them in zere's directory on dev
17:27:53 <gravitystorm> apmon: are they live, or only created after the meeting ends?
17:28:26 <gravitystorm> answers that
17:28:32 <gravitystorm> i.e. live
17:29:00 <gravitystorm> OK, that's been 10+ mins on this topic, pnorman I'm not sure where we go from here.
17:30:35 <gravitystorm> I'll minute this as "general lack of interest, pnorman welcome to discuss labelling with maintainers as required" or something similar!
17:30:41 <apmon> Labeling probably mostly makes sense if there are multiple developers to assign tickets to
17:30:44 <tmcw> gravitystorm: re: labelling. there are only two types of labelling that I've seen work - labelling of type ('design', 'bug', 'enhancement'), and labelling pull requests based on whether they're ready to merge
17:31:12 <tmcw> and, of course, assigning is always useful when there are multiple devs on it
17:31:39 <tmcw> I would be very +1 for openstreetmap-website to use the 'bug' label, for instance
17:31:59 <apmon> it might also make some sense for the style-sheet that gets large quanteties of tickets
17:32:35 <gravitystorm> apmon: indeed, we're using labels with openstreetmap-carto already
17:32:47 <gravitystorm> tmcw: thanks, good information.
17:33:14 <shaunmcdonald> opinion on what, it's not clear
17:33:42 <pnorman> yes - I have access to osm-carto solely to label so that andy can see immediately that half the stuff is "please render <X>"
17:33:53 <apmon> I wouldn't see it as much help for e.g. osm2pgsql or mod_tile
17:35:34 <gravitystorm> OK, so are there any actions from this discussion?
17:35:38 <shaunmcdonald> I see labels more useful when you have more issues, and longer term issues that are going to linger for a while.
17:37:03 <gravitystorm> #topic  publicity around moderately large updates to the website
17:37:12 <gravitystorm> pnorman: over to you again!
17:37:54 <pnorman> heh. well, leaving aside many of the complaints on talk@, we do need some better way to announce that there is some moderately significant UI change being discussed
17:37:59 <apmon> Perhaps the announcement can tie in with getting translations into the repository before deployment... ;-)
17:39:16 <RichardF> gravitystorm: P2's still on trac. It'll move to github once it's no longer the default editor but for now it's not something I've looked at
17:39:31 <pnorman> Frederik did something of that nature with I was wondering about Pascal's weekly OSM updates, sending him a note if there's something significant under discussion, where it gets in the weekly summary.
17:39:33 <RichardF> (P2 issues, I mean, the code's on github obviously)
17:40:30 <gravitystorm> pnorman: do you think that more publicity will get *better* feedback than what we currently get on pull requests, or just *more* feedback?
17:40:34 <pnorman> It shouldn't slow down development, the time from merge-ready pull request to the merge is long enough for people to see it and comment
17:41:35 <gravitystorm> pnorman: and are you looking for more people to get a better survey of sentiments, or to find more bugs/edgecases etc?
17:41:59 <apmon> pnorman: It would be helpful if a more specific time is given when the merge will occur to motivate people to look at the preview
17:42:16 <pnorman> gravitystorm: well, this is more about informing people. getting effective feedback and making good use of it is a different issue, and I don't have any great ideas on that issue
17:44:00 <tmcw> pnorman: we've tinkered with the idea of announcing earlier
17:44:46 <tmcw> iD has lots of pre-press, the 'attribution mark' got a few posts ahead of time
17:45:20 <tmcw> the concept may work if we're extremely strict with "what the thread is about"
17:45:38 <tmcw> because otherwise it becomes a "don't launch until everyone is consulted and happy" which is literally never ever
17:45:43 <apmon> tmcw: One problem I find is, that announcements are currently from "Here is some new cool new ideas and the may or may not be merged in a year" to "Oh buy the way it was deployed last week"
17:46:04 <pnorman> Should we be directing commentary to the lists or to the relevant pull request?
17:46:25 <tmcw> the latter.
17:46:41 <tmcw> well, depends on what you mean by commentary
17:47:16 <apmon> On design you will never get everyone happy. It is a question of trying to figure out if at least the majority is happy with it
17:47:29 <tmcw> I don't think that's a valid poitn.
17:47:43 <tmcw> The majority of people on talk lists are angry. Now, forever.
17:48:00 <apmon> Yes, I didn't say talk was a good way to judge that
17:48:40 <tmcw> Okay, then... what's the alternative?
17:49:01 <lonvia> I believe an announcement on talk@ at the time of the merge that explains the ideas behind the change would have already done lots to calm down the discussion.
17:49:08 <apmon> I don't know, but that is something we should try and figure out as a group if there is a better way
17:49:25 <pnorman> tmcw: well, you've said in the past for iD you want it on github
17:49:54 <gravitystorm> So I disagree with the idea of soliciting "sentiments" from people on design issues. It's fine to have opinions on the general process (who the design lead is / who the cartographer is / who approves deployment) but beyond that it's bikeshedding. Soliciting "bug reports" by previewing design stuff can, on the other hand, be useful.
17:50:06 <tmcw> lonvia: I did that with iD and it was a trainwreck. The same exact level of unproductive flaming
17:52:42 <apmon> gravitystorm: why do you think soliciting sentiments is a bad idea on a subjective topic as design?
17:53:03 <gravitystorm> apmon: because you get bikeshedding and flames and rarely anything actionable
17:53:08 <tmcw> ^ that.
17:53:58 <gravitystorm> it's why I'd never say "Here's the new colours for openstreetmap-carto, what do people think?" but I would say "here's my rewriting of the roads code, anyone spot any bugs here?"
17:56:29 <gravitystorm> So I'm in favour of communicating more about what changes have been made (i.e. announcing at the point of deployment) and I'm in favour of soliciting many-eyes checking of pull requests, which I think we have already, right?
17:58:15 <gravitystorm> pnorman: any thoughts/actions that you see arising?
18:00:00 <pnorman> it feels like we're taking the route of hiding away design decisions
18:00:40 <gravitystorm> pnorman: by having them on pull requests and previewed on **
18:00:41 <gravitystorm> ?
18:01:32 <gravitystorm> sorry, I slipped off of my "chair" chair and back into the discussion again :-)
18:01:52 <gravitystorm> I'd like to wrap things up for this meeting, perhaps we can revisit this next week
18:01:56 <apmon> few people will read the pull-requests, as most of them are irrelevant to them
18:02:25 <pnorman> by not letting anyone outside rails-dev@ and people watching the github repo know. rails-dev@ is probably the highest traffic list with all the pull stuff going to it, unless you've got the time to read everything you won't know what's a minor bug fix and what impacts end-users
18:03:22 <gravitystorm> pnorman: apmon: so if you think there's a reason to notify people *before* the pull request is merged, then outline what you would like the outcome to be
18:04:05 <apmon> Well, if you put off any feedback as bikeshedding and flames, then not much...
18:05:15 <apmon> but you will get those discussions afterwards anyway and they are not going to be more positive then either
18:06:02 <gravitystorm> apmon: examples of feedback that are: a) neither bikeshedding nor flames b) not already considered by the designers and c) not forthcoming without pre-announcing merge requests - would help focus this discussion
18:06:25 <apmon> On a different topic. Would it be possible to discuss the idea of extending some more for better testing next time?
18:06:40 <gravitystorm> apmon: sounds like a good topic for next week
18:07:15 <apmon> e.g making it into a wider used resource for developers who work on osm related projects?
18:08:30 <tmcw> apmon: it seems like one of the vital issues is "you must invest time / energy in order to participate in any process"
18:12:26 <gravitystorm> Anyone else before I close the meeting?