Attendees
| IRC nick
|
Real name
|
| apmon |
Kai Krueger
|
| pnorman |
Paul Norman
|
| ppawel |
Paweł Paprota
|
| TomH |
Tom Hughes
|
| zere |
Matt Amos
|
Summary
- Notes/bugs branch
- [1] "Anonymous users shouldn't be able to close notes"
- AGREED: Anonymous users shouldn't be able to close notes
- [2] "Timeout for sending comments in the popup"
- AGREED: stick with free text input for now, and re-examine after launch.
- [3] "Make /browse/note more in line with other /browse pages"
- AGREED: relative time is better, despite the points raised by zverik, and either <abbr> or <time> looks like the appropriate markup.
- [4] '"Add a note" link is too well hidden'
- AGREED: to leave "add note" UI as it is, and look again after it is deployed.
- [5] "Add a sentence to note adding popup to encourage users to write some basic details."
- AGREED: "In order to improve the map the information you enter is shown to other mappers, so please be as descriptive and precise as possible when moving the marker to the correct position and entering your note below."
- AoB
- osm2pgsql db on dev: apmon to announce its availability on the dev mailing list.
IRC Log
18:05:09 <zere> minutes of the previous (very short) meeting: http://www.osmfoundation.org/wiki/Working_Group_Minutes/EWG_2013-01-21
18:05:18 <zere> #topic notes branch
18:06:12 <zere> TomH: are these the tickets? https://github.com/tomhughes/openstreetmap-website/issues
18:06:22 <TomH> yep
18:06:45 <zere> #link https://github.com/tomhughes/openstreetmap-website/issues/25 "Anonymous users shouldn't be able to close notes"
18:07:24 <zere> i don't feel strongly either way about this... what are the pros/cons of this?
18:08:31 <zere> i guess you could say that a note/bug would be closed after an edit to the map, so it doesn't make much sense to allow anon closing of notes.
18:09:10 <zere> but i guess there could be situations where anon closing would be useful, e.g: dupes, mistakes and so forth where otherwise it would have to be done by a logged-in user.
18:10:15 <TomH> it's easy enough to do and I guess it does make reasonable sense
18:10:40 <zere> i don't have any objection. anybody else?
18:12:22 <zere> #agreed Anonymous users shouldn't be able to close notes
18:12:46 <zere> #link https://github.com/tomhughes/openstreetmap-website/issues/28 "Timeout for sending comments in the popup"
18:13:16 <TomH> oh yeah that probably doesn't really need a policy decision
18:13:26 <zere> not sure i understand what this one is about anyway...
18:13:38 <zere> something about errors, timeouts and buttons being disabled?
18:14:29 <TomH> well basically the UI doesn't nothing at the moment if the ajax request errors or times out
18:14:53 <zere> ok, i guess that doesn't need a decision... it's just a bug, right?
18:15:03 <TomH> now this is mostly an issue when passenger is starting up, which is common on the dev server but rare on the live site
18:15:19 <ppawel> TomH, do you think it makes sense to discuss the issue I and Sylvain raised with note structure or is this discussion closed? for reference: https://github.com/tomhughes/openstreetmap-website/issues/33
18:15:51 <ppawel> what concerns me about it is basically http://lists.openstreetmap.org/pipermail/dev/2012-November/026232.html
18:17:00 <TomH> well that overlaps with https://github.com/tomhughes/openstreetmap-website/issues/41 to some extent
18:17:03 <ppawel> in short there is potentially point to be made that "free text" notes will lower the "quality" of bugs reported
18:17:20 <TomH> but the point is we decided all this ages ago, that we didn't want to put lots of obstacles in the ay of reports
18:17:48 <TomH> comparing it to OSB is probably not very useful, as hopefully mappers will see the built in notes a lot mre than they do OSB
18:18:22 <TomH> especially if we make efforts to auto surface it in place of mapdust in potlatch say
18:19:27 <apmon> mapdust used categories. And although they were helpful in many ways, they seemed to encourage to not actually write any helpful explaining text
18:20:00 <zere> i sympathise with sylvain's point - having too many"noise" notes will make the whole thing less useful... but i'm hesitant to change to fixed-form bug reporting (not that we might not think that's a good idea in the future) or anything else which would make it harder for people to contribute...
18:20:06 <ppawel> if you are worried about delaying deployment because of this then I already said that I can volunteer the time to develop some kind of simple UI (perhaps google maps-like but simpler category screen) and rails side
18:20:33 <apmon> Fixed form bugs would loose much of the benefit of OSB imho
18:20:46 <ppawel> I don't want to "hijack" notes with that request - I am just concerned that deploying free text notes is a one way street
18:21:02 <ppawel> whereas we can always go the other way - drop categories if people don't like them
18:21:16 <apmon> I missed the beginning of the discussion, but imho we should "launch" it as it is and then adapt later on as it becomes necessary
18:21:44 <zere> it's entirely possible to layer forms & categories on top of free text notes at a later date. maybe even quite quickly, if we get good feedback that it would be better...
18:22:20 <ppawel> well then you would get a lot of notes in
18:22:32 <ppawel> in 'other' category or 'no category' something like that..
18:23:02 <apmon> Imho, if we are worried about too much useless bugs, requiring loging on with a osm account would be more productive in ensuring less noise.
18:23:03 <zere> yeah, it's possible. and we might have to go back and have a drive to classify old notes
18:23:30 <zere> i quite like sylvain's idea to auto-expire old bugs, though. but that's perhaps a different discussion...
18:25:02 <zere> as to this point - it seems to be a question of whether to stick with what we've got.
18:25:08 <ppawel> well anyway that was just my opinion, by no means it should block anything, especially that it's very close to the finish line
18:25:31 <ppawel> (or perhaps deployment = starting line should I say :)
18:25:39 <apmon> Unless there are automated bots that spam the db, I would guess we can develop extensions fast enough to cope with any real world issues once they crop up retrospectively
18:25:59 <zere> what do you think? stick with what we have (+1) or re-examine the free text / fixed-form UI (-1)?
18:26:11 <apmon> +1
18:26:12 <ppawel> +1
18:26:22 <zere> +1 from me too.
18:26:54 <zere> #agreed stick with free text input for now, and re-examine after launch.
18:27:11 <apmon> How close to launching is it?
18:27:12 <zere> #link https://github.com/tomhughes/openstreetmap-website/issues/32 "Make /browse/note more in line with other /browse pages"
18:27:37 <zere> i think it's just these tickets to go through, and then the work of resolving them... TomH?
18:28:32 <apmon> sweet
18:28:37 <ppawel> I think the relative time ("1 year ago") issue would probably require a consistent approach across the site
18:29:23 <zere> i think TomH was suggesting that if might change all over the site if it works well on the notes pages.
18:29:24 <TomH> zere: I think so, yes
18:29:46 <TomH> that was my vague though when writing the "friendly" date stuff yes
18:30:08 <TomH> not my invention - other site do the "hover for full date" thing
18:30:14 <TomH> trac was probably where I saw it first
18:30:24 <TomH> github does it as well
18:30:27 <zere> personally, i find that relative time is generally much more useful, except for things which were a long time ago (e.g: 4 years ago - probably more useful to have 2009-02-11 to me)
18:30:41 <zere> is it <abbr>?
18:31:20 <TomH> think it is just a span, but cna change that
18:32:04 <zere> ah, i've seen it done with <abbr> before, and styled with a nice dotted underline which made it a little more obvious it could be clicked / hovered.
18:32:41 <apmon> giving some hint that it can be hovered would be good.
18:33:18 <ppawel> zere, that's what I'm using for the history tab, the dotting is nice
18:34:01 <ppawel> plus the cursor is different on hover
18:34:05 <zere> yup
18:34:44 <ppawel> I use jquery plugin (timeago) that does this automatically but it's just a matter of css I guess..
18:35:08 <zere> it sounds like we're in agreement - relative time is better, despite the points raised by zverik, and <abbr> is the appropriate markup (assuming we're not ready for html5 <time> yet)?
18:35:17 <zere> any objections?
18:35:40 <TomH> html5 time sounds good as well
18:36:03 <zere> depends how many people are visiting with html5 capable browsers
18:37:55 <zere> #agreed relative time is better, despite the points raised by zverik, and either <abbr> or <time> looks like the appropriate markup.
18:38:19 <zere> #link https://github.com/tomhughes/openstreetmap-website/issues/40 '"Add a note" link is too well hidden'
18:38:56 * pnorman checks in
18:39:24 <zere> the question here is: leave the "add a note" link in the bottom right - not very prominent - and come back to it later, or try and make a decision now about what its prominence should be and where it fits in the UI?
18:40:17 <TomH> well I kind of hope somebody with design chops will do something with it if we get it out there
18:40:42 <zere> personally, i agree with TomH and zverik's comments - we know it's not great but, unless there's a better suggestion, i don't think we should let it hold up deployment
18:40:43 <apmon> The non prominance of the link is one of my biggest issues with the current design, but I also don't really know how to make it better
18:41:26 <ppawel> maybe a link on the tab bar ('add note' or 'notes')?
18:41:27 <apmon> So I am +1 on leaving it for now and hopeing someone will suggest a better solution once it is merged
18:41:37 <ppawel> that may be too prominent..
18:41:54 <apmon> It also matches the UI of google maps
18:42:49 <zere> in general, there's probably a lot that can be done to improve the UI across the site. but that's a big project and i wouldn't want notes/bugs to get stuck behind that...
18:43:41 <zere> a show of hands: +1 to leave it as it is, and look again after it is deployed. -1 to look again now?
18:44:03 <apmon> +1
18:44:10 <pnorman> +1 to getting it out soon
18:44:31 <ppawel> +1 indeed
18:44:49 * zere encounters a "relative time" problem - github just updated to show TomH's comment "in a few seconds". oops ;-)
18:45:07 <zere> #agreed to leave "add note" UI as it is, and look again after it is deployed.
18:45:10 <pnorman> zere: yes, that's normal for me too
18:45:35 <zere> #link https://github.com/tomhughes/openstreetmap-website/issues/41 "Add a sentence to note adding popup to encourage users to write some basic details."
18:46:27 <zere> this seems to be about whether we want to put some text above the bug/note description to suggest / encourage what users should write.
18:47:21 <apmon> I see a slightly more fundamental issue, that currently it does not make clear that a note is a bug report and that it is publicly visible
18:47:32 <zere> we're looking for either: no, let's not put anything there (maybe space is too much of a premium already), yes (but we don't know what to write), yes (we should say "...")
18:47:40 <apmon> I.e. that it is not meant for "I ate my lunch here" kind of notes
18:48:08 <ppawel> well there is nothing to suggest otherwise ;)
18:48:12 <zere> fair enough... but how to put that into words? preferably helpful for a complete novice...
18:50:50 <zere> "please enter your note below. it will be shown to other mappers in this area, so please be as descriptive and precise as possible in your explanation of the problem."
18:50:53 <zere> how's that?
18:51:51 <apmon> Yes that sounds reasonable
18:51:58 <apmon> I came up with "Please help improve the quality of the map by reporting an issues as accurately as possible with the current map. Your note will be publicly visible and used by other members of the community to update the map to reflect reality."
18:53:46 <apmon> Well, it still needs to include the "Move the marker to the correct position" part
18:54:14 <zere> "please move the marker to the correct position and enter your note below. it will be shown to other mappers in this area, so please be as descriptive and precise as possible in your explanation of the problem."
18:56:38 <apmon> I think the first sentence needs to state the purpose. I.e. that it is used to correct / improve the actual map
18:57:46 <apmon> I am wondering if it might be useful to have a "more..." link in the header as well which links to a page that explains the process
18:58:12 <zere> "the information you enter will be shown to other mappers in this area in order to improve the map, so please be as descriptive and precise as possible when moving the marker to the correct position and entering your note below."?
18:58:41 <apmon> i.e. that the notes relies on other people to correct the data and that if the report is not descriptive or there are no mappers in the area it might take "for ever" to fix
18:59:05 <apmon> and that one can always just fix the issue one self (which is the preferred method) if one feels comfortable with that
18:59:29 <apmon> zere: Yes that sounds better
19:00:36 <zere> any other comments? +1 to agree with the above, -1 to disagree :-)
19:00:56 <apmon> +1
19:01:59 <pnorman> +1 to content, but the end of the sentence reads badly
19:03:54 <zere> "the information you enter will be shown to other mappers in this area in order to improvethe map, so please be as precise as possible when moving the marker to thecorrect position and as descriptive as possible when writing your explanation below"?
19:03:58 <zere> is that any better?
19:04:24 <zere> modulo copy & paste missing spaces, of course ;-)
19:05:43 <pnorman> I think the first is better, but I think there's a tense shift going on
19:06:02 <pnorman> perhaps s/will be shown/is shown/
19:08:40 <apmon> Was that the last of the notes issues to be discussed?
19:10:13 <zere> hmm? "the information you enter is shown to other mappers in this area in order to improve the map, so please be as descriptive and precise as possible when moving the marker to the correct position and entering your note below."?
19:10:57 <zere> "the information you enter is shown to other mappers in this area so they can improve the map, so please be as descriptive and precise as possible when moving the marker to the correct position and entering your note below."?
19:11:04 <ppawel> remove 'in this area'? it's actually shown to all mappers
19:11:33 <zere> well, i was thinking that the note would probably only be visible in the area near the marker
19:11:42 <pnorman> "In order to improve the map the information you enter is shown to other mappers, so please be as descriptive and precise as possible when moving the marker to the correct position and entering your note below."
19:12:21 <zere> +1 pnorman's version
19:13:37 * pnorman is the son of an editor, and sometimes it shows
19:17:05 <zere> i'm going to consider this as an agreement, then...
19:17:19 <zere> #agreed "In order to improve the map the information you enter is shown to other mappers, so please be as descriptive and precise as possible when moving the marker to the correct position and entering your note below."
19:17:32 <zere> yay! we managed to get through all the tickets :-)
19:17:32 <TomH> already added to the ticket ;-)
19:18:13 <zere> awesome. is there any other (preferably really, really quick) business?
19:18:13 <apmon> :-)
19:18:19 <zere> #topic AoB
19:18:37 <apmon> osm2pgsql db on dev
19:18:55 <apmon> It is up and running for anyone to use and replicating
19:19:08 <apmon> Should I announce it as available on dev?
19:19:23 <pnorman> apmon: I had some access issues which got resolved. I think it could use some publicity, as well as the fact that dev.osm.org is usable now that OWL isn't running on it
19:20:01 <pnorman> I've been wondering about setting up a local noname layer based on it as none of the existing ones get the logic quite right for around here
19:20:10 <zere> apmon: sure - please feel free to announce it.
19:20:25 <zere> might it also be worth putting together something for CWG about this?
19:20:32 <apmon> OK will write an email to dev at some point then
19:23:16 <zere> cool. i'll try and remember to bring up the CWG thing next time. and meeting frequency too.
19:23:26 <zere> thanks to everyone for coming & have a great week :-)