Attendees
| 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
|
Summary
- 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.
IRC Log
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 http://www.openstreetmap.org/?lat=57.011&lon=-6.428&zoom=10&layers=M 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> http://matt.dev.openstreetmap.org/osm-ewg/2013/osm-ewg.2013-07-22-17.05.log.txt 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 http://lists.openstreetmap.org/pipermail/talk/2013-July/067632.html. 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 *.apis.dev*
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 ci.osm.org 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?