Attendees
| IRC nick
|
Real name
|
| apmon_ |
Kai Krueger
|
| gravitystorm |
Andy Allan
|
| pnorman |
Paul Norman
|
| RichardF |
Richard Fairhurst
|
| TomH |
Tom Hughes
|
| zere |
Matt Amos
|
Summary
- Actions of previous meetings
- gravitystorm still working on READMEs.
- zere hasn't looked at the OWL install docs yet.
- Filtering notes
- The question was whether notes having categories or some other filtering mechanism would be useful.
- There wasn't much enthusiasm for discussing, so we will revisit categories, filtering for notes at a later date.
- Retaining developers post-hackday
- There were around 40 people on at the post-SOTM-US hackday, some of whom probably had never contributed code to OSM before. What can we do to help convert some of them to more regular code contributors?
- Need more information about what is attracting them to OSM / stopping them from contributing further. Then we can target efforts.
- Post-hackday survey https://hackpad.com/OpenStreetMap-sprint-followup-questionaire-JzH1Bmv0ncJ
- ACTION: apmon to come up with some questions for the post-hackday survey
- Notes branch
- Want to provide a way for clients (software) to identify themselves.
- Current hack is to match the OAuth client key against the OAuth tables and just store the ID along with the note. (Although no OAuth actually takes place.)
- Tying client OAuth to key means version bumps would need re-auth, so probably wouldn't happen. This limits the usefulness, as client version is often a very important factor in finding regressions.
- Rails port docs
- maptile_for_point DB functions complicate the install process, and are only used for "changes" API calls, which are only hit about once an hour by a single user as far as we can tell.
- The general feeling was that we would like to remove this API call, but will need to manage the deprecation process and announce it.
IRC Log
17:01:26 <zere> minutes of the last meeting, please let me know if anything needs correcting. http://www.osmfoundation.org/wiki/Working_Group_Minutes/EWG_2013-06-03
17:02:18 <gravitystorm> zere: looks good to me
17:02:24 <zere> #topic actions of previous meetings
17:02:33 <zere> gravitystorm: what's the latest on the readme stuff?
17:02:55 <gravitystorm> still bumbling along - I only really get a chance to do stuff during these meetings
17:03:20 <gravitystorm> or perhaps it's the sense of guilt is at a maximum during the meetings. Same net effect
17:03:31 <zere> cool. anything you need / want help with?
17:05:47 <gravitystorm> Not yet. In about 1-2 man-hours time, it would be great for someone to follow the installation instructions in a VM and see whether they are accurate
17:06:55 <zere> ok. i had an action on me to look at the OWL install instructions, but i haven't managed to do that yet. i'll have to carry it over to the next meeting.
17:08:04 <zere> we had one item for discussion which we ran out of time for, about having categories and/or filtering for notes.
17:08:09 <zere> #topic filtering notes
17:08:48 <pnorman> I had some stuff I wanted to talk about for retaining developers from the code sprint after sotm-us too
17:09:08 <zere> apmon brought it up, but isn't here today. basically the question was whether notes having categories or some other filtering mechanism would be useful.
17:09:09 <TomH> I've got a notes issue as well
17:09:29 <TomH> well we decided not to complicate notes for now and to see how things went didn't we?
17:09:49 <TomH> (before we deployed them)
17:10:25 <zere> yup, so the question is whehter now is a good time to see how things went, or whether we leave it for a future time.
17:11:37 <zere> i'm not sensing a massive enthusiasm for discussing it now, so let's leave it for later.
17:12:07 <zere> #idea revisit categories, filtering for notes at a later date.
17:12:09 <RichardF> I think the only feature request I've seen some consensus around is reopening notes - otherwise people seem largely happy with it
17:13:03 <zere> ok, let's go in the order these were raised.
17:13:17 <zere> #topic retaining developers post-hackday
17:13:27 <pnorman> We had probably 40 people on Monday, some of whom probably had never contributed code to OSM before
17:13:40 <zere> great!
17:13:54 <TomH> RichardF: reopening has been live for a week!
17:14:01 <pnorman> What can we do to help convert some of them to more regular code contributors?
17:15:12 <RichardF> TomH: ha! that's what I get for being jetlagged the last week ;)
17:15:38 <zere> it's a good question, and i can't think of a simple answer. do they need support - mentoring, task selection, that sort of thing?
17:17:05 <pnorman> I suppose one option would be to send out a message (dev, talk-us) asking people who were at the code sprint what it would take to get them contributing code to OSM more regularly - simply asking might get 1-2 to think about it and start
17:17:44 <zere> are many of them already subscribed to one of those mailing lists?
17:18:11 <pnorman> good question. perhaps not, but I can't think of another way to reach them besides twitter and other social media
17:19:31 <zere> is it worth putting together some sort of questionnaire about their experience and what could be done to keep them engaged, then post a link to that on dev, talk-us and tweet from the sotm-us account (assuming they're happy to do it, of course)
17:20:01 <TomH> there's a list of names of people that signed up beforehand at http://osmsprintdays.eventbrite.com/
17:21:28 <pnorman> 44 people on that list!
17:26:53 <pnorman> a rough count has 30 people being new, or at least not regular contruibtors. If we're doing a questionnaire, how do we want to write the questions?
17:27:50 <zere> it would be useful to know if they found the format to be helpful, and whether they think it was effective for learning & gaining enthusiasm
17:28:00 <gravitystorm> 1) Did you enjoy the hack day 2) have you contributed since 3) why not?
17:28:14 <gravitystorm> albeit I'm making assumptions :-)
17:29:19 <zere> i guess we want to ask if they have any interest in contributing any more and, if so, what are the barriers to doing so - e.g: learning curve, knowing where to start, getting dev environments set up, code commit procedures, etc...
17:30:18 <zere> does anyone feel like volunteering to put such a survey together? my feeling is that this is better done while the event and associated enthusiasm are still strong
17:30:35 <zere> while the *memory* of the event, rather.
17:34:25 <gravitystorm> Tumbleweed
17:34:42 <zere> was that you volunteering, gravitystorm?
17:34:49 <zere> :-P
17:35:02 <gravitystorm> I'm not volunteering by the way, given my lack of progress on the rails docs. And the list of OWG-based followups from SOTM too
17:35:45 <zere> pnorman: would you like to put together a few questions?
17:36:44 <pnorman> argh. my list is like andy's (although not nearly so lucrative). I wouldn't normally suggest using meeting for it, but perhaps right now?
17:37:11 <zere> ok, let's discuss TomH's notes issue first and come back to it?
17:37:15 <zere> #topic notes branch
17:37:23 <zere> TomH: what's the issue?
17:38:25 <TomH> so I want to provide a way for clients to identify themselves
17:38:41 <zere> a sort of created_by?
17:38:45 <TomH> now for authenticated clients it's easy - we can store the oauth client id
17:39:12 <TomH> yep, exactly, because otherwise there is often no way to identify the client program if there is a problem
17:40:27 <TomH> so for unauthed clients what I was thinking of (and did a test implementation of at the hack days) was for them to register an oauth client and pass the key in an application_key parameter
17:41:15 <TomH> for now I would make it optional, with then intention of making it required once we have tried to identify users and get them to add it
17:41:28 <zere> that seems a little kludgy
17:41:36 <TomH> well do you have a better idea?
17:42:12 <zere> isn't it easier to include a "user-agent" key in the notes payload?
17:42:43 <TomH> well yse we could just make everybody send an arbitrary string and record that
17:43:12 <TomH> would use more storage would we require that even for authed clients?
17:43:15 <RichardF> (brief followup to earlier issue - sorry, I'm ducking in and out - maybe ask emacsen to do the questionnaire? he organised the hack days after all)
17:49:06 <zere> TomH: so the alternative is to match the oauth client key against the oauth tables and just store the ID (bigint?) in along with the note?
17:49:15 <zere> if i've understood you correctly.
17:49:33 <TomH> yeah that's what my current hack does
17:50:16 <gravitystorm> on another side note, I've now moved onto testing the rails port install notes, and I have a couple of questions when we're done with the current topic
17:50:59 <zere> well, if it works then that's already in its favour. it doesn't seem a nice way of doing it to me, but i don't have a better suggestion, so i'd say just go for it.
17:51:58 <pnorman> for those not following oauth or rails stuff: https://hackpad.com/OpenStreetMap-sprint-followup-questionaire-JzH1Bmv0ncJ
17:54:04 <zere> although i guess if it's tied to an oauth client ID then it's not going to change with the versions (people won't want to have to re-auth a new client for each version bump), and isn't havign the version information very useful?
17:55:19 <TomH> I guess that's a good point
17:56:25 <zere> although easy enough to ask for a key and a version number (smallint or something). probably not a big deal, but an opaque string is easier for the app dev.
17:56:55 <zere> perhaps having a client_strings table which is just a map<int, string> to uniquify the strings?
17:57:38 <TomH> could do... I'll think about it some more
17:57:56 <zere> cool.
17:58:29 <zere> #topic rails port docs
17:58:35 <zere> i think that was the next one, right?
17:58:46 <zere> gravitystorm: you had a couple of questions?
17:59:18 <gravitystorm> yep - https://github.com/gravitystorm/openstreetmap-website/blob/docs/INSTALL.md#potlatch-2
17:59:40 <gravitystorm> when you set up the rails port, you have to jump through hoops to get p2 working. Is the same needed for iD?
18:00:00 <TomH> well it will need an oauth key yes
18:00:07 <TomH> so do the notes
18:00:28 <gravitystorm> ok
18:00:37 * gravitystorm notes a note about notes
18:00:37 <TomH> potlatch2_key, id_key and oauth_key in the applicaton.yml
18:00:57 <gravitystorm> second question: https://github.com/gravitystorm/openstreetmap-website/blob/docs/INSTALL.md#postgresql-quadtile-functions
18:01:10 <gravitystorm> are the quadtile functions used for anything other than the changes API?
18:02:14 <zere> i think they're overridden and have ruby implemetnations for everything else
18:02:33 <zere> iirc, for a pure ruby install + test, the changes tests are the only ones which fail
18:02:38 <TomH> yes there are ruby versions of them all if the C ones aren't built
18:03:24 <TomH> the changes call fails if the DB functions are missing, not the quadtile functions
18:03:38 <TomH> because it uses the maptile_for_point DB function
18:03:56 <zere> well, they are the db quadtile functions, right?
18:04:08 <TomH> well strictly speaking that one isn't
18:04:16 <TomH> it does map tiles, not quad tiles
18:04:27 <zere> anyway, i'm pretty sure noone is using changes API any more - can we get rid of it?
18:04:38 <gravitystorm> zere: that's where I was heading :-)
18:04:44 <TomH> fair point, that was for t@h...
18:05:26 <apmon> You might want to check the logs to verify that it really isn't used anymore
18:05:34 <TomH> I have one user by the looks of it
18:06:24 <TomH> once an hour a machine at OVH France checks it
18:06:57 <TomH> possibly the french proxy thing?
18:07:11 <pnorman> no, that's pure overpass on the backend
18:08:27 <gravitystorm> TomH: is there anything using xid_to_int4 function?
18:08:36 <TomH> only osmosis for the replication feed
18:09:25 <TomH> but the title of that secton is kind of wrong anyway given that only one of the three functions is anything to do with quadtiles ;-)
18:09:43 <gravitystorm> TomH: indeed, I've just realised this from reading all the function definitions
18:09:53 <TomH> I think tile_for_point is used by one of the migrations?
18:10:27 <TomH> ah it is, but with a fallback
18:10:55 <zere> yeah, i usually develop without those functions, and just put up with "expecting" the changes tests to fail.
18:11:20 <zere> so they can definitely go. the only question is how do we announce it, and can we get in touch with this single user?
18:13:29 <pnorman> dev@ and talk-fr@?
18:14:41 <zere> sure, i was hoping we could just contact that single user. perhaps it's an old thing running, and we can just switch off changes tomorrow.
18:15:19 <zere> but i can't see any identifying information, the UA is "-" and DNS reverse lookup isn't helpful.
18:15:38 <pnorman> well we could block them for violating the user-agent policy and then we'd have no users :)
18:15:46 <zere> gravitystorm: more questions?
18:15:59 <gravitystorm> zere: not at the moment, thanks
18:16:08 <zere> awesome. back to the survey
18:16:19 <zere> #topic post-hackday survey
18:16:29 <pnorman> https://hackpad.com/OpenStreetMap-sprint-followup-questionaire-JzH1Bmv0ncJ
18:16:41 <zere> pnorman: thanks for putting that together
18:17:17 <zere> do we want to think about questions now, or do we have a volunteer (apmon?)
18:18:19 <apmon> volunteer? For what?
18:19:18 <apmon> to add more questions?
18:20:16 <zere> we were discussing having a questionnaire for attendees at the hackday(s) post-SOTM-US as many of them were new contributors, and we'd like to know how we can help them continue to contribute.
18:20:31 <pnorman> we want get newcomers who were at the hack day to become regular code contributors, and see if there's anything blocking them from doing so
18:20:38 <apmon> Yes sounds good.
18:20:47 <zere> pnorman and gravitystorm are pretty solidly booked, so we were looking for a volunteer to put something together so we can figure out how best to help them
18:21:06 <apmon> There definately seemed to be a lot of people outside of the main rooms, that presumably were new to core OSM development
18:21:52 <apmon> not sure how much interaction there was with people who are part of the "familiar dev team"
18:22:19 <apmon> so that possibly could have been organised better, to integrate new commers more
18:23:10 <zere> apmon: does that mean you're volunteering?
18:23:33 <apmon> to add questions? Yes, I can try and come up with some.
18:23:40 <zere> excellent, thanks :-)
18:24:00 <zere> #action apmon to come up with some questions for the post-hackday survey
18:24:01 <apmon> but it is probably best if everyone contrinutes, as everyone has different points of view what might be important
18:24:24 <zere> yes, absolutely, it's something we can all help out with
18:25:06 <zere> #topic AoB
18:25:14 <pnorman> there's a MT meeting later today, so if anyone has anything for your MT rep to bring up, now would be a good time to mention it
18:25:30 <zere> uhh... tonight? i thought it was tomorrow?
18:25:42 * pnorman doesn't do time zones well
18:25:43 <pnorman> checking
18:26:53 <pnorman> right you are
18:27:43 <pnorman> in any case, still a good time to mention anything :)
18:27:52 <zere> indeed
18:30:21 <pnorman> 8 PM BST, 7 PM GMT, noon PDST
18:30:47 <zere> well, if anyone thinks of anything they'd like to see raised, then please let me know.
18:31:04 <zere> thanks for coming, and see you next week :-)
