Attendees
| IRC nick
|
Real name
|
| apmon_ |
Kai Krueger
|
| pnorman |
Paul Norman
|
| ppawel |
Paweł Paprota
|
| tmcw |
Tom MacWright
|
| TomH |
Tom Hughes
|
| zere |
Matt Amos
|
Summary
- Notes/bugs
- Wikipedia identifies anonymous users from their IP addresses, but there was a great deal of concern that this would be against many EU data protection policies. However, the availability of IP addresses is extremely useful for counteracting abuse and vandalism.
- AGREED: We should store IP with notes, but not display it.
- The legal issue surrounding anonymous users has not been resolved. apmon_ started a discussion on $MAILING_LIST, but it did not lead to any clear consensus. The common options seem to be:
- Disallow anonymous notes: everyone needs to sign in / create an account.
- Allow anonymous notes, but anonymous users are presented with a click-through agreement to ensure data is OK for re-use in OSM.
- Allow anonymous notes, but users viewing the notes get a warning saying "the source of this data cannot be verified, please verify using other sources"?
- AGREED: for the moment, add a (short!) warning banner to anon notes linked to a longer explanation of why the data cannot be verified legally and must be independently verified.
- For reference, the current notes branch head is at [1].
IRC Log
18:20:20 <zere> #startmeeting
18:20:20 <ewg-meetbot> Meeting started Mon Nov 19 18:20:20 2012 UTC. The chair is zere. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:20:20 <ewg-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:20:39 <zere> apologies for the late start, everyone.
18:21:07 <zere> i'm behind on the minutes, but the log of last meeting is available at http://matt.dev.openstreetmap.org/osm-ewg/2012/osm-ewg.2012-11-12-18.04.html for your reference.
18:22:21 <zere> we only had one action from the last meeting, on apmon_ to take the "anon notes" question to an appropriate mailing list, which i see he has done: http://lists.openstreetmap.org/pipermail/osmf-talk/2012-November/001908.html
18:22:36 <zere> apmon_: anything to report on that, or is discussion still on-going?
18:23:24 <apmon_> It pretty much lead to the expected result: A mix of oppinions
18:23:44 <apmon_> and reflects the same arguments as were made on other lists where the topic was brought up
18:23:50 <zere> any one opinion more prevalent than the others? was there the chance of consensus?
18:24:22 <TomH> well they got a bit distracted from the question and started bikeshedding the whole thing
18:27:16 <apmon_> A number of additional suggests were made, like adding the ability to add an email address to anonymous notes.
18:27:26 <zere> so we're still left with the options: 1) no anon notes - everyone needs to sign in. 2) anon notes, but anon users are presented with some sort of click-through to ensure data is CT-OK. 3) anon notes are allowed, but the users viewing the notes get a warning saying "the source of this data cannot be verified, please verify using CT-OK sources"?
18:27:36 <apmon_> I.e. basically have all the same information as during account creation, but with out the "account"
18:27:46 <apmon_> which imho probably doesn't make too much sense
18:28:21 <zere> that's option (2) basically - they go through a click-through to collect data and agree they'er not entering encumbered data?
18:28:42 <apmon_> plus providing an email address for communication
18:29:07 <apmon_> yes, more or less (2)
18:30:00 <apmon_> So who is going to make this decision now?
18:30:40 <zere> do we have a consensus here? if so, i'd say let's just make the decision and get on with it. otherwise we could go around in circles for ages
18:30:59 <zere> if it turns out later that there was a good reason to choose something else... well, that's a pain point we'll have to deal with
18:31:38 <zere> personally, i think (3) is easiest from the contribution point of view... might be the weakest from a legal point of view
18:31:39 <apmon_> No real consensus from the lists, but I doubt we will ever get one. So someone just has to make the decision or we will go around in circles.
18:31:50 <zere> well, i vote (3). anyone else?
18:32:23 <apmon_> I vote for an initial (1) with the option to go to (3) should (1) work out well.
18:32:23 <ppawel> 2 or 3 for me
18:33:04 <TomH> UI wise (3) is problematic
18:33:20 <zere> really? i would have thought it would be the easiest?
18:33:26 <TomH> UI wise (2) involves doing work which I'd like to avoid
18:33:44 <TomH> zere: well one is easiest because it's just removing stuff
18:34:09 <apmon_> Yes, (2) seems like a lot work work duplicating things that are all ready available in (1)
18:34:12 <zere> TomH: why is (3) problematic?
18:34:18 <TomH> three is logically trivial, but involves trying to work out how to stop the bubble covering the entire map when you add a legal essay to it
18:34:29 <ppawel> aren't 2 and 3 just a paragraph of some random text?
18:34:37 <TomH> yes that's the easy bit
18:34:50 <TomH> but because notes appear in popup bubble on the map we need to keep them small
18:34:57 <zere> oh, i was thinking it would be a short sentence, linked to a longer explanation....
18:35:05 <TomH> well ok that might work
18:35:08 <ppawel> some link like 'legal info'
18:35:28 <ppawel> though IANAL and not sure if that's enough legally...
18:35:43 <zere> well, "Warning: The legal status of this data has not been verified."?
18:35:47 <TomH> would we keep the ability for the user to enter a name?
18:35:50 <apmon_> Where it would say the name of the reporter / commenter for logged in users, it would have a short explanation for anon
18:35:54 <TomH> or just remove that feature
18:36:37 <TomH> yeah I guess instead of "by TomH" it could be "by anon" where anon had a tooltip and linked to a page with a warning
18:37:46 <apmon_> For anon users, would it still store the IP from where the message was posted?
18:38:17 <TomH> probably a good idea
18:38:29 <zere> if i understood TomH correctly, then even if we stored it, we couldn't display it. but it's probably good from an auditability point of view
18:38:41 <zere> e.g: if we get a lot of copyrighted "notes" from a single source
18:38:50 <TomH> and if we have problems we would easily be able to see what address to block
18:38:56 <zere> yup
18:38:57 <apmon_> Yes, currently it is never revealed, but stored for purposes of abuse protection
18:38:59 <zere> ok
18:39:15 <zere> #topic Notes/bugs
18:39:23 <zere> #agreed should store IP, but not display it
18:40:07 <zere> #agreed for the moment, add a (short!) warning banner to anon notes linked to a longer explanation of why the data cannot be verified legally
18:40:33 <zere> anything else on anon notes, or notes branch generally?
18:41:13 <apmon_> OK, so it would require to remove the author_name field from the note_comments table
18:41:30 <TomH> yes - it shoudn't be hard - will try and look at it this week
18:42:00 <apmon_> I had a look at the nearby_place aspect of the notes
18:42:12 <apmon_> Removing that is also very easy.
18:42:46 <apmon_> But one question remains. In the rss feed, the nearby place was part of the title of the note, to be able to quickly identify it in text
18:43:24 <apmon_> Should that be replaced with a lookup of the place on creating the rss view, or just not included at all?
18:44:34 <apmon_> Given that rss viewers regularly poll the rss feed, doing a nominatim lookup for each note in the feed might be expensive
18:45:03 <TomH> that can be cached though - look at what the diary view does
18:47:42 <apmon_> OK, I'll see that I'll extend the views to include the caching then
18:50:08 <apmon_> Any other blockers for the notes branch left then?
18:56:58 <zere> i'll take that as a "no".
18:57:33 <tmcw> Er
18:57:47 <tmcw> Just getting in now, but will it be clobbered by a Leaflet merge?
18:58:10 <zere> i guess, but perhaps only in some front-endy bits
18:58:13 <pnorman> hmm
18:58:17 * pnorman checks in
18:59:19 <tmcw> this is the openstreetbugs branch, right? https://github.com/openstreetmap/openstreetmap-website/compare/master...openstreetbugs
18:59:39 <zere> i thought it was called "notes" nowadays?
18:59:52 <zere> apmon_: ^^ ?
18:59:56 <tmcw> there's no notes branch on github
19:00:05 <apmon_> https://github.com/tomhughes/openstreetmap-website/tree/notes
19:00:48 <tmcw> yeah, https://github.com/tomhughes/openstreetmap-website/blob/notes/app/assets/javascripts/index/notes.js.erb
19:01:04 <tmcw> this will get pwned by leaflet. so we need to decide an order, and I'd say the leaflet merge is a higher priority.
19:01:21 <TomH> yes my plan was to do leaflet first
19:01:31 <apmon_> tmcw: What makes you think that leaflet is higher priority?
19:01:33 <pnorman> For some reason I thought the meeting was starting now, did daylight savings screw me up?
19:02:17 <zere> pnorman: we'd arranged to keep the meetnig at the same time when Europe changed off DST, so yes - in teh US it moved when DST ended
19:02:36 <TomH> only for one week until the US moved off DST as well
19:02:54 <apmon_> notes is an important feature, while the leaflet merge is mostly a stylistic or internal
19:02:58 <tmcw> no
19:03:27 <zere> TomH: does it make it more difficult if one in particular is merged after the other? either way, whichever one gets in first will force changes in the other
19:03:27 <TomH> apmon_: yes but it makes no sense to merge notes and then change the UI a few weeks later to move to leaflet
19:03:30 <tmcw> the leaflet merge affects other branches. if we don't merge it before them, then there will be more work to redo.
19:04:07 <zere> tmcw: i don't think so. the work will be redone in any case, it's just a question of which branch it's done on.
19:04:28 <zere> from what jfire said, it seemed that it was fairly straightforward
19:04:33 <TomH> zere: well no, but I reluctant to spend any time on polishing notes when any code changes will be immediately obseleted
19:05:00 <zere> only OL-specific code, surely?
19:05:18 <TomH> and leaflet is basically ready to merge (module working out what to do about vendorer and the various vendor assets) while notes isn't quite
19:05:39 <TomH> zere: sure
19:06:23 <zere> then we're debating nothing: leaflet will merge first because it's "readier" - it has nothing to do with priority or what would need re-writing.
19:07:34 <TomH> probably, yes
19:08:06 <ppawel> then can we move on?
19:10:27 <zere> yes, let's move on
19:12:24 <zere> last week we had a brief discussion of putting bounties on some of the TTTs which aren't moving forward as fast as we'd like. anyone want to continue that discussion?
19:14:27 <ppawel> yes, I'd be interested in learning what are the plans for bounties, is there something planned for the next year etc. I see that in 2012 EWG Plan there was some money allocated but apparently most of the issues were not critical enough to contract stuff..
19:15:23 <ppawel> it interests me as I'd like to keep working on OSM stuff in the capacity I do (somewhere between part/full time)
19:16:17 <ppawel> it would be ideal if I could get sponsoring for the work that I want to do (OWL, social things) but other things will do just as well..
19:16:37 <zere> the reason it was included in the plan is exactly that - we find out during the course of the year which tasks move forward and which ones don't. then try to "stimulate" the ones which don't look like they're going to get done any time soon under their own power.
19:19:39 <ppawel> ok, so what is the current status?
19:20:42 <zere> first off, do we want to do this? if so, which tasks should be eligable, and to what amount?
19:24:44 <zere> well, that's not exactly the overwhelming endorsement i was hoping for.
19:24:44 <ppawel> I suspect that in some cases no bounty = task won't be fully done for a looong time, so that's also a question for some strategic meeting..
19:25:39 <zere> sure. when we review at the beginning of next year we can see what worked and what didn't and adjust the plan for the following year
19:26:02 <apmon_> zere: Which task could actually benefit from a bounty?
19:26:08 <zere> that's our "strategic meeting" - although i hate the whole management-speak "strategy"...
19:26:31 <ppawel> for example, I'd like to get OWL to the finish line but there's still A LOT of work to do... so it's sadly very simple - either I get some sponsoring and work on it further for some months or I probably have to leave it half-baked because of lack of time
19:27:06 <ppawel> zere, I just meant some priorities for tasks, what tasks should have the bounty incentive etc.. not sure how this happens, I've never seen how TTT list gets compiled
19:27:11 <zere> i think we were talking about: help.osm.org i18n, clickable (rendering-dependent) POIs, routing frontend, deleted items API call
19:27:13 <pnorman> Should bounties go to ones that are partially done or ones which are basically at the start
19:27:54 <zere> pnorman: that's the question - if they're moving, perhaps there's no point putting a bounty on them. if they've stalled, perhaps there is.
19:28:20 <ppawel> sure it's better to have volunteers, for many reasons (including financial ones)...
19:28:26 <apmon_> routing front end seems currently blocked on the merge of leaflet and notes
19:29:13 <apmon_> deleted items API call seems like the main contender for a bounty
19:29:49 <apmon_> as that one is actually blocked on that no one has moved forward to implement it
19:29:54 <pnorman> I doubt the deleted items API is likely to progress without one
19:30:44 <zere> yup. i keep wanting to do it, but finding that it's halfway down my TODO list, and not moving up particularly quickly
19:30:49 <apmon_> So perhaps that would be a good candidate to try the concept out
19:30:50 <zere> it's a tough one, though.
19:31:33 <pnorman> yes, the other tasks are partially integration ones, deleted is starting new functionality from scratch
19:31:52 <zere> i would say the same for "clickable (rendering-dependent)" - what's missing here is someone to do it (maybe based on gravitystorm's carto rewrite?)
19:33:48 <apmon_> clickable POIs is likely the second contender, but my guess would be that that will more quickly be bottlenecked by integration and operations issues than the delete API functionality
19:34:08 <zere> maybe, but that's part of the task ;-)
19:34:50 <zere> the prize award was initially intended to be 100 GBP (125 EUR / 160 USD). do we want to keep that, and try it out on these two tasks?
19:34:54 <apmon_> But unless they get admin rights, that is not something that is in the control of the person who would receive the bounty
19:35:52 <pnorman> the undelete api stuff is also something that can only sensibly be done on osm.org servers, third parties can implement clickable POIs independently
19:35:52 <apmon_> +1 for the deleted API call
19:36:06 <zere> apmon_: neither is deployment of deleted items API call - we'll have to decide at the point of award whether enough has been done to qualify.
19:36:38 <ppawel> oh my, I misread the EWG plan, I thought it was 2k per task, not 2k per 20 tasks.......
19:36:47 <ppawel> I guess I need to look for sponsoring elsewhere...
19:37:09 <apmon_> Yes, it is a bounty for volunteers. Not a contractual payment
19:37:14 <zere> well, yes - the bounties are quite small.
19:37:50 <zere> there is actually contract money too - but really as a last resort if the developer community really isn't able to handle the task
19:38:19 <apmon_> I.e. to convince people who would potentially do it anyway to shift it up to the top of their todo list
19:40:06 <pnorman> I'd be interested and might go after one with a bounty if they didn't basically all require rails
19:41:15 <zere> that's the idea - it was never intended to provide a living wage, just to give people a reason to do a TTT rather than something else.
19:41:39 <zere> pnorman: not tempted by the clickable one? that doesn't need any rails.
19:42:11 <zere> mod_tile, renderd, mapnik, carto (maybe), and some leaflet.
19:42:24 <apmon_> would the delete API be in rails, or in cgimap, or both?
19:42:45 <pnorman> I wouldn't touch that until the leaflet change is done and my UI skills are minimal
19:43:33 <apmon_> Ah, so that task is blocked straight a way on integration... ;-)
19:47:16 <apmon_> So how would we progress on setting up a bounty?
19:48:07 <apmon_> I suspect one would have to define a set of requirements that minimally need to be achieved to be eligible for the bounty?
19:51:38 <apmon_> Is that something we should put on the agenda for next week?
19:52:37 <pnorman> Yes - didn't OSMF set up some framework for hiring contractors? I know this is somewhat different but it might be worth looking over that material
19:57:05 <zere> pnorman: uhhh, sort of. that task is blocked on me, i'm afraid.
19:57:21 <zere> but most of it is legal boilerplate.
19:57:29 <zere> i think the bounties can be much more lightweight
19:57:54 <zere> basically, i think we can just decide to disburse them when we think the task is "done enough".
19:59:20 <apmon_> Imho what "done enough" is should be to a degree defined before hand to not end up with the goal posts moving too much and frustrating people
19:59:44 <zere> sure
20:00:06 <zere> we've been going 1.5h - is it worth discussing that now, or leave it until next week?
20:00:27 <zere> we could also do a bit of thinking about these tasks and what "done enough" could mean
20:00:40 <apmon_> probably next week
20:00:52 <zere> i don't necessarily think it has to be "deployed and working", but that would be the best outcome.
20:01:09 <zere> ok, let's leave it for next week.
20:01:23 <zere> thanks to everyone for coming. hope to see you next week!
20:01:26 <zere> #endmeeting