Attendees
| IRC nick
|
Real name
|
| apmon |
Kai Krueger
|
| gravitystorm |
Andy Allan
|
| iandees |
Ian Dees
|
| pnorman |
Paul Norman
|
| shaunmcdonald |
Shaun McDonald
|
| TomH |
Tom Hughes
|
| zere |
Matt Amos
|
Summary
- GSoC
- There was discussion around what could be done to improve submissions. General agreement that mentors need to be involved, but no concrete actions were taken.
- Review of the "Top Ten Tasks" for ability to convert into GSoC projects. One strong contender is "clickable POIs", which could include building utfgrid support into mod_tile/renderd.
- Osm2pgsql
- pnorman verified that a small patch is responsible for the difference in line counts & lengths on the threading branch [1].
- Consensus was that it was a performance optimisation only, and could be backed out to merge the threading branch.
IRC Log
17:30:47 <zere> welcome, EWGers :-)
17:31:13 <zere> minutes of the last meeting: http://www.osmfoundation.org/wiki/Working_Group_Minutes/EWG_2014-02-10 please let me know if there's anything which needs changing.
17:31:33 <zere> we have two actions from previous meetings, and one agenda item.
17:31:38 <zere> #topic actions
17:32:01 <zere> ah, well, it seems apmon isn't here, so we'll have to ask about CM some other time.
17:32:14 <zere> RichardF: how goes the "couple of little things"? ;-)
17:32:33 <TomH> I suspect RichardF may be away as well as it's half term
17:33:51 <zere> how is the routing branch looking this week? same as last week?
17:35:01 <zere> apmon: hi! not wanting to jump on you, but; any word re: CM routing backend?
17:40:13 <apmon> No, still didn't do it.
17:40:24 <zere> ok, no worries.
17:40:32 <apmon> But given the delays in coming along with the development, I think it isn't as critical yet
17:40:59 <zere> yup, and there are plenty of other backends anyway.
17:41:06 <zere> #topic osm2pgsql
17:41:37 <zere> apologies to pnorman, i didn't check with him at AoB last time, so (if he's around) we can go to him first
17:45:14 <zere> hmmm... i guess he's not around either.
17:45:27 <zere> #topic AoB
17:45:33 <zere> anyone else want to discuss anything?
17:46:08 <apmon> are we done with all the normal discussions?
17:47:08 <zere> everything that was on the agenda & all the actions for everyone who is here, yeah ;-)
17:50:00 <apmon> one potential AoB: GSoC?
17:50:35 <zere> sure, how's that going?
17:50:40 <zere> #topic GSoC
17:50:51 <apmon> Well, that is the question...
17:51:09 <apmon> Do we have a good set of potential projects?
17:52:06 <gravitystorm> http://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2014/Project_Ideas
17:53:04 <apmon> It feels like dispite "always" complaining about lack of developers, we can't get good core project proposals out
17:54:36 <apmon> So perhaps the EWG could get involved and ensure there are good ones available, for the website or other important core projects
17:54:48 <zere> i don't know about anyone else, but the issue for me is mentoring. i'd put forward project proposals, but i can't commit to supervising and mentoring the candidate well enough to produce merge-quality code.
17:55:29 <zere> and i don't think it's helpful to put forward project proposals without people committed to mentoring them to success.
17:55:45 <gravitystorm> zere: I was just writing that I believe it's mentoring that's the issue, and proposals are a symptom
17:55:57 <apmon> Yes, mentors are pretty important
17:56:15 <zere> the retrospectives on GSoC from the haskell community clearly show that, even with good mentoring, something like 50% of the projects fail. and bad/absent mentoring can only increase that.
17:56:31 <gravitystorm> so perhaps it should be that we look at our major projects, and find which ones don't have any mentors, and then enquire from the maintainers as to why
17:56:33 <apmon> but is our developer community really so non existent that we can't get mentors?
17:57:02 <TomH> and any project really needs to be adding to an existing code base, not building something new from scratch, or there will be no life to it once the student departs
17:57:10 <zere> well, s/non existent/busy/, perhaps.
17:57:32 <zere> apmon: would you mentor a project on improvements to osm2pgsql, for example?
17:57:35 <apmon> TomH: imho, that is at least partly due to the failure of putting up good proposals in the past
17:57:51 <apmon> people then just jumped in to add ideas that weren't great
17:58:40 <apmon> and if we want to accept specific students to a project or if we think the students aren't going to be good is still up for later, but without good ideas, we will definately not get good students.
17:59:00 <apmon> zere: Yes, I could
17:59:34 <gravitystorm> apmon: ... and without good mentors, we're not going to get good proposals. So I think it again goes back to the question of discussing with maintainers whether they (or they have someone on their team who) fancies mentoring
17:59:35 <zere> who is reviewing (accepting / rejecting) ideas for OSM's GSoC?
17:59:44 <apmon> So if you have some good potential ideas lets discuss them and see if we can do somethinging in that respect
17:59:49 <gravitystorm> zere: iandees is running it afaik
18:00:17 * iandees peers around
18:00:20 <apmon> the reviewing and accepting is done amongst all of the potential mentors
18:00:33 <iandees> Kate and I are, yes. however this year we're working with OSGeo again.
18:01:04 <zere> because, quite frankly, i think in previous years we've (fsvo "we") done it arse-backwards; with the aim of entering GSoC, some random ideas have been collected, then due to the badness of the ideas and/or mentors and/or students, the results are left on the shelf / never finished / never worked / never wanted in the first place.
18:01:34 <shaunmcdonald> I wonder if the students coming up with their own idea works better than working on something that someone else has thought up?
18:01:48 <apmon> hence, why I would like to make sure we get the good ideas out first... ;-)
18:02:23 <iandees> shaunmcdonald: if we had a bunch of great students clamoring at our doorstep i would say that the students could present great ideas, but we haven't had that in the past
18:02:26 <apmon> shaunmcdonald: They can always do that, but chances of finding a good mentor are even slimmer in that case
18:02:45 <zere> ok. what i was trying to get at was that 1) good ideas aren't enough. 2) bad ideas have to be rejected.
18:02:48 <shaunmcdonald> fair points
18:03:26 <iandees> zere: agree, with the caveat that mentoring doesn't need to be a huge time sink if we have the right students.
18:03:30 <shaunmcdonald> I remember the localisation of the website code, which I basically had to re-write.
18:03:49 * pnorman waves
18:03:51 <apmon> There are also positive examples
18:04:02 <zere> iandees: but you can't guarantee that up-front, right? you need to assume that mentoring will be a significant committment.
18:04:25 <iandees> zere: you put into it what you can. you can't assume that it will be significant either.
18:05:03 <iandees> if mentors were paid by google i would say we should expect some base amount of work from them, but they aren't.
18:06:08 <iandees> a gsoc term doesn't entirely succeed or fail on a mentor's shoulders. it's mostly the student.
18:06:14 <apmon> The mentor can decide how much effort they put into it.
18:06:18 <zere> right, but this is what puts me off: if i put into it what i can, there's a good chance it won't be very much. the likelihood is that most students will need some mentoring, and will suffer from its lack. therefore, as a mentor, if i'm not able to put much into it then the failure is on my head.
18:06:49 <pnorman> I believe GSoC expects a certain minimum level of mentoring from mentors
18:07:05 <apmon> If it is a good dynamic between mentor and student, then either the amount that is needed isn't overwhelming, because the student does most of the things, or the large amount of work is needed because the student is really productive
18:07:47 <apmon> if the dynamic between mentor and student isn't great, then either the student isn't good and you just ignore them after a while and potentially fail them.
18:08:15 <iandees> but... the question is what can/should EWG do?
18:08:16 <iandees> if anything
18:08:19 <apmon> Or let the student do what they are doing, if they are productive, but just not in the right way. OSM might not benefit in that case, but the mentor doesn't loose to much either
18:08:29 <shaunmcdonald> I wonder if it's possible for 2 mentors to share the role?
18:08:57 <apmon> as zere suggested, we could try and identify and talk to the relevant maintainers and try and encourage them to participate and setup proposals.
18:09:08 <zere> if what we want out of this is that projects are a success (and part of that is that the code gets merged), then we should work backwards from the goal.
18:09:14 <apmon> If I am not mistaken, there are backup and co mentors
18:09:43 <iandees> zere: indeed, so what are some bugs that could be done in a summer?
18:10:23 <zere> apmon: i don't think it needs to be a project maintainer, just someone who is able to commit time and effort, and in a project which is actually looking to take that patch.
18:11:26 <gravitystorm> my suggesting maintainers went along the lines of they're a good place to start if there are no other volunteers from that project. Or at least they are in a position to say whether a particular mentor knows enough about the project to mentor the student successfully
18:11:33 <zere> iandees: well, take your pick from https://github.com/openstreetmap/openstreetmap-website/issues?direction=desc&sort=updated&state=open - most are probably too easy, some might be too hard.
18:12:40 <zere> but, imho, the major issue is still finding people to mentor with the ability to commit time/effort.
18:12:48 <apmon> having someone with commit rights to a project (maintainer) by in is fairly important to get things merged in the end
18:13:10 <gravitystorm> and if the maintainer is involved, even if just suggesting alternative mentors, the chances of goal alignment and eventual merging must be higher
18:13:12 <gravitystorm> apmon: exactly
18:14:03 <apmon> With respect to osm2pgsql and mod_tile, one of my issues is that I don't really use the software (run tileserver) so I don't experience the issues people are having my self
18:14:12 <zere> well... i'd say the most important factor in getting something merged is writing it well, and it being something that's actually wanted.
18:14:17 <apmon> So good ideas of what people really want and would use is always appreciated
18:15:03 <gravitystorm> Ideas of what *committers* really want, preferably
18:15:34 <gravitystorm> and since Set [:committers] == Set [:maintainers] for most of our projects.... :-)
18:15:47 <apmon> should be a combination. If commiters want it but no user cares about it, it might not be ideal either
18:16:41 <apmon> Can any of the "top ten tasks" be converted into a GSoC project?
18:17:50 <zere> i was looking through that too
18:18:06 <zere> i think support for multiple languages on help.osm.org is lacking a maintainer
18:18:19 <zere> clickable POIs could work, if a mentor could be found
18:18:25 <apmon> gravitystorm: From your work as a consultant, do you have reoccuring feature requests (for mod_tile / renderd) that might lend themselves for GSoC projects?
18:18:36 <zere> routing is (fingers crossed) going to be done before GSoC starts
18:18:46 <apmon> imho the groups project could be another one
18:18:57 <gravitystorm> apmon: utfgrid support
18:19:01 <zere> the deleted items call could, assuming a mentor could be found.
18:19:03 <apmon> if we can get RichardF to be involved
18:19:14 <apmon> gravitystorm: Yes, that was the one I was thinking about as well.
18:19:42 <apmon> I was just wondering if that might be to simple a task though, as all the support is already in mapnik.
18:19:54 <zere> for improved activity / history, i guess we'd have to see if ppawel would mentor - i'm not sure anyone else knows about OWL ;-)
18:20:10 <apmon> But I usually underestimate time things take, so if there are a couple of extra things one can add, utfgrid support does sound good.
18:20:46 <gravitystorm> apmon: utfgrid support, with a sideline in integrating it into the rails_port as clickable pois :-)
18:20:49 <pnorman> apmon: well if you start writing tests for if your new feature works, then you get into writing a whole test infrastructure
18:21:04 <apmon> pnorman: :-)
18:21:24 <apmon> gravitystorm: Yes, that sounds good. I'll write something up and put it onto the project ideas page
18:22:01 <apmon> pnorman: Btw, is all of your cgimap code deployed by now? ;-)
18:22:29 <pnorman> well pgsnapshot code isn't, but I think all the supported calls are deployed
18:22:48 <pnorman> and it brought the germany relation/full time down from a timeout at 5 minutes to under 30 seconds
18:23:13 <apmon> Thats a good example of a successfull GSoC project then!
18:23:54 <zere> that was a GSoC project?
18:24:37 <apmon> pnorman: That was yours wasn't it?
18:24:40 <pnorman> yes
18:25:27 <zere> am i looking in the wrong place? http://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2013/Project_Ideas
18:25:49 <pnorman> those are project ideas - a student can submit any proposal they want
18:29:09 <apmon> perhaps, that makes it even more successfull if people don't even know it was a GSoC project
18:29:48 <apmon> Anyway, is there something actionable here?
18:29:59 <zere> pnorman: who was mentoring you?
18:30:04 <pnorman> iandees
18:30:28 <zere> nice.
18:30:31 <apmon> zere: Weren't you at least co-mentoring him (not officially, but practically(
18:31:17 <zere> we interacted a lot, but then i'm the maintainer of cgimap, so that's to be expected. i didn't feel like i was mentoring, just collaborating with a contributor.
18:31:36 <apmon> zere: Exactly, that is how the relation should be
18:34:06 <zere> ok, so... anything actionable
18:34:07 <zere> ?
18:34:30 <zere> sounds like we have one good idea (utfgrid in osm2pgsql + clickable POIs on osm.org)?
18:35:08 <apmon> perhaps someone could ask the developers of iD if they have ideas (and capacity to mentor)
18:36:23 <zere> any volunteers to take that one?
18:36:39 <iandees> i have previously asked mapbox about it with no interest
18:36:46 <zere> oh, balls.
18:36:48 <iandees> i can ask jfire specifically
18:37:06 <zere> thanks. even if he says no, that would be good to know.
18:37:47 * iandees nods
18:38:02 <pnorman> my item is https://github.com/openstreetmap/osm2pgsql/pull/110
18:40:51 <zere> pnorman: awesome, it's basically all done?
18:41:06 <pnorman> no
18:41:51 <pnorman> My testing was a hack to verify that those lines caused the issue. I must admit, I don't understand what those lines do, and if the old behavior is correct
18:43:13 <apmon> Is that the index issue?
18:43:44 <pnorman> my fix has the issue that you have to manually create indexes mid-import
18:46:00 <apmon> If I remember correctly, the intention was to move https://github.com/openstreetmap/osm2pgsql/pull/110/files#diff-8647d42f728e3cd81a88ef0c2b3151ecL917 to the end
18:46:31 <apmon> Adding an index you don't need during import and then running a cluster to rearrange everything anway doesn't make sense
18:46:43 <apmon> so I tried to move the index creating after clustering
18:47:25 <apmon> there were some places where the index was needed, but I (wrongly) though those lines had no effect during initial import and were only needed during diff-import
18:47:37 <apmon> hence commenting them out to allow the moving of the index
18:47:41 <pnorman> so we do need the changes my patch did - so I guess we need to move the index creation back to the start
18:48:04 <apmon> there clearly are conditions though were those lines did something afterall in the initial import as well
18:49:06 <apmon> yes, unless we can understand why those lines are executed and figure out that they shouldn't have been and the new behaviour is correct, that indeed seems like the most appropriate action
18:49:25 <apmon> it was only a speed optimization if I remember correct, so undoing it shouldn't be an issue
18:52:26 <zere> ok. cool. was there anything else?
18:54:37 <zere> i guess not?
18:55:26 <zere> ok. thanks to everyone for coming, and hope to see you next week!
