Attendees
| IRC nick
|
Real name
|
| apmon |
Kai Krueger
|
| migurski |
Michal Migurski
|
| mvexel |
Martijn van Exel
|
| RichardF |
Richard Fairhurst
|
| tmcw |
Tom MacWright
|
| zere |
Matt Amos
|
Summary
- zere gave an overview of the license change rails_port code.
- Github branch is here [1].
- And a running dev instance for testing [2].
- What still needs to be done:
- Review / fix bugs.
- Changes to Osmosis, history dump tool to support redaction.
- Activity streams / user page as dashboard
- ajturner and tmcw have both been working on this.
- There was discussion of how to best implement summary statistics at the user level - number of changes, friends, edits - that sort of thing.
- Human-readable summaries ("<user> has been editing around [cities / regions] in the last month") would be very useful. zere commented that some of these things seem a good fit for OWL.
- Status of OWL.
- Database on new server (zark) was up-to-date just as the database was taken offline.
- API still in flux - needs work. Nothing stable to write against at present.
- mvexel to reorganise the user account settings page into 'profile' and 'settings' sections.
- Time slot is not convenient for all, will re-assess next meeting.
IRC Log
19:00 < RichardF> hellooo
19:00 < zere> we have 2 sets of minutes this meeting http://www.osmfoundation.org/wiki/Working_Group_Minutes/EWG_2012-03-12 and http://www.osmfoundation.org/wiki/Working_Group_Minutes/EWG_2012-03-26 - as always, please let me know if there's anything wrong there.
19:00 -!- migurski [~migurski@173-164-158-185-SFBA.hfc.comcastbusiness.net] has joined #osm-ewg
19:00 < zere> draft agenda for this meeting: license change, design stuff, AoB
19:02 < migurski> Present.
19:03 < zere> license change stuff: as i'm sure you'll all have noticed, we're down for the DB migration. the plan calls for the rails_port code to be ready pretty ASAP as soon as that's over...
19:03 < zere> so i invite you all to review, check and otherwise fiddle with the redaction branch, https://github.com/zerebubuth/openstreetmap-website/tree/redaction
19:03 < zere> and the running instance on the dev server: http://redaction.apis.dev.openstreetmap.org/
19:04 -!- ajturner [~ajturner@63-147-135-190.dia.static.qwest.net] has joined #osm-ewg
19:04 -!- ajturner [~ajturner@63-147-135-190.dia.static.qwest.net] has quit []
19:05 < zere> the changes in there so far ad an extra resource "redactions", API calls to redact historical (i.e: not current_* version) elements by associating them with a redaction and tries to hide redacted elements from all API calls and browse pages.
19:06 < zere> i'm hoping that, at this point, it's pretty much "done", barring bugs and/or refactorings to make the code better.
19:10 < apmon_> zere: Is it possible that the changeset browse page is still missing the redaction changes?
19:11 < zere> hmmm... i thought i added that in 9371385...
19:12 < zere> rather, they're not removed from the changeset browse - they appear to be deleted.
19:12 < zere> although on second thought, i should have used a different CSS class for them.
19:14 < apmon_> Yes, I think that would make it more obvious
19:14 < RichardF> so what's remaining to be done with the licence change stuff?
19:15 < zere> the changes to the rails port code need to be reviewed - to give us some confidence in them
19:15 < apmon_> What is the interface between the license change bot and the db?
19:16 < zere> then there are changes to osmosis & history dump tools to be made (although i think they'll be pretty easy)
19:16 < zere> and the interface, as apmon_ says, between the license change code and the API/DB. although i'm hoping the way i've structured it will make that easy too.
19:18 < apmon_> will it be going through the rails_port api, or access the db directly?
19:19 < zere> undecided as yet
19:19 -!- mvexel [~mvexel@c-71-199-51-114.hsd1.ut.comcast.net] has joined #osm-ewg
19:19 < zere> i'd prefer to go through the API, as it's safer. but that has problems of its own
19:19 * mvexel sneaks in late
19:20 < apmon_> In case it goes through the API, it would go through the new redaction code?
19:20 < zere> yes, exactly. it would use the new redaction API calls
19:22 < apmon_> The current logic of how to redact remain in the license bot rather than in the redact API?
19:23 < apmon_> i.e. the removal of the redacted information from the current version by creating a new version
19:23 < zere> yes, that's in the license bot
19:23 < zere> if it interfaced direct to the DB it would have to embed some logic for the table schema, which i'd rather avoid. but it's pretty much single-use code at the moment...
19:24 < zere> might be able to make a decent tool out of it later, i suppose, but it doesn't weigh heavily on my mind at the moment ;-)
19:27 < zere> ok. we're approaching halfway, and the discussion seems to have stalled slightly. i hope there are no objections if we move onto the design stuff?
19:28 < zere> and if anyone is able to give a summary of where we're at with that / where we're headed? i'm afraid to say i've been mainly focussing on the license stuff, and i'm not up to speed.
19:29 < migurski> Unfortunately due to time change I'm here splitting my attention between a standing 11am meeting and this, but I'm very interested in participating in the design discussion as you know
19:30 < mvexel> As far as I can see there are a few parallel and interwoven threads in the design work
19:30 < mvexel> There's the user page redesign, andrew submitted initial work for that
19:31 < mvexel> There's the small incremental UX improvements tmcw has been submitting
19:31 < zere> cool. is there work in the pipeline to make andrew's initial work into a full-fledged item?
19:31 < mvexel> And then there's the bigger theme of making OSM more social and its implications on the website
19:31 < mvexel> following mikel's blog post of a few days ago
19:31 -!- tmcw [~tmcw@63-147-135-190.dia.static.qwest.net] has joined #osm-ewg
19:32 < mvexel> I am not sure if he has had time to work on it more, but I'm sure he and tmcw have discussing it at wherecamp / where
19:33 < tmcw> yo
19:33 < zere> sounds good. is there anything we should be discussing here, or is it all cruising the rails at the moment?
19:33 < tmcw> I missed wherecamp, unfortunately
19:33 < mvexel> oh hi tmcw
19:33 < tmcw> O hi
19:33 < mvexel> we were just talking about the user page redesign
19:33 < mvexel> and if any more work had been done on that
19:33 < tmcw> word, yeah, none on my side at least
19:34 < mvexel> I saw you closed your pull request related to that
19:34 < mvexel> commenting that andrew's was more mature
19:34 < tmcw> Yeah, would rather focus on one effort, and turner got farther than I did
19:34 < tmcw> the fork's still around if we want to manually port some code for it
19:35 < mvexel> one thing I'd want to focus on is the content of that activity stream
19:35 < mvexel> as it is it's diary entries from friends and changesets by friends, iirc
19:36 < mvexel> the bigger goal is for the user page to become more of a dashboard, a logical landing page for logged in users
19:36 < mvexel> right?
19:38 < zere> that certainly sounds good to me, and could be hooked into an "events" stream either from the wiki or built in.
19:38 < zere> people have been asking for that for *ages*
19:39 < zere> and having it on a dashboard, where it's a pull-based interaction, rather than sending out a massive stream of emails seems like a good choice.
19:39 < mvexel> yes, that would mean that we would need to architect an 'event' abstract class / interface (I am not too familiar with ruby...) that diary entry / changeset / events classes could be implementations of - does that sound about right?
19:41 < mvexel> what other things would you want to carry over from your user page redesign tmcw ?
19:41 < zere> ruby's looser than that - we can easily dynamically apply templates based on the class type and no common interface is necessary.
19:41 < mvexel> zere: sounds like a breeze. :)
19:42 < tmcw> Getting a really sweet activity stream or whatnot is definitely cool, and would be even better if someone with great ror chops could do it
19:42 < tmcw> My actual big priority for the user page, besides just making it prettier, is to add commit & friend totals
19:42 < tmcw> which is relatively simple unless you want to be precise about nodes and deleting and whatever
19:44 < zere> the changesets have a num_changes column which is semi-accurate, were you thinking of using that/
19:44 < zere> ?
19:44 < tmcw> yep
19:44 < tmcw> even just number of changesets would be handy
19:45 < mvexel> i agree more of an osm contribution dimension to the osm persona would be very very good
19:45 < tmcw> some big numbers that are approximate indicators of user activity and accomplishment I think are cheap tech-wise and pretty useful ux-wise
19:45 < mvexel> next step: <user> has been editing around [cities / regions] in the last month
19:46 < zere> Changesets.sum(:num_changes).where(:user => @this_user) or something like that?
19:47 < zere> mvexel: that would be an excellent fit for the OWL query structure, i think... it's designed to answer those geo-recently queries efficiently.
19:48 < mvexel> cool. what's OWL's status btw?
19:49 < tmcw> zere: definitely, but I think that should be in a second push
19:49 < zere> the instance on zark just caught up as we were taking the DB offline (rats!)
19:49 < tmcw> .count is simpler/cheaper in ror and less dependent on the fate of other stuff
19:50 < zere> sure, just depends on whether it matters that .count penalises people with larger changesets, and potentially encourages people to over-submit small changesets to increase their numbers. but it may not matter.
19:51 < zere> and i agree - don't wait on OWL for any features. i can't give you any promises about when it'll be up & running.
19:52 < mvexel> I think at first it's OK - people will need time to get accustomed to the user page changes so we probably won't see those dynamics emerging right away
19:52 < mvexel> zere: does the old OWL url not redirect to the new instance yet?
19:53 < migurski> might we take a pre-emptive approach to this, and incr/decr values and deal with places when the edits happen, rather than when the user page is viewed?
19:53 < zere> 'fraid not - got overtaken with all this license change work. the DB is now up on zark, but not the new front-end to deal with the schema changes.
19:53 < mvexel> zere: ok thx
19:54 < mvexel> migurski: sounds like the way to go to me
19:54 < migurski> this stuff also sounds like it can be dark-launched as needed
19:54 < zere> migurski: if it gets to be a problem, we can always cache those sums in memcached. but as tmcw was saying, i think it's likely the overhead of that query won't be too large.
19:54 < migurski> right
19:54 * mvexel wonders about schema changes needed to hold user stats
19:55 < tmcw> sorry, mostly preparing for a presentation right now and don't have much bandwidth
19:56 < tmcw> basically, yeah - like any kind of user 'count' will be subject to inaccuracy, like people who upload 5,000 photos of their face to flickr
19:57 < mvexel> one other thing - I was going to reorganize the user account settings page into a 'profile' and 'settings' section, sound good?
19:57 < zere> yup. it's probably not an issue unless the importance of the statistic gets overstated...
19:57 < mvexel> not introducing any changes on the back end, just reorganize the settings into logical blocks
19:58 < zere> http://jqueryui.com/demos/accordion/ ?
19:58 * migurski cries
19:59 < zere> oh, is that Bad Design? sorry ;-)
19:59 < mvexel> zere: no that would stand out like a sore thumb I think
20:00 < migurski> it's just mysterious
20:00 < migurski> hiding/ showing
20:01 < zere> are tabs better for that?
20:02 < mvexel> I was just thinking (for now) of two headers, one 'profile' one 'settings' and possibly a links to anchors at the top
20:02 < migurski> yeah tabs are nice, just links that are obviously clickable
20:03 < zere> i never figured that tabs were particularly intuitive, but now everyone's got them on their ipad safari so they've been learned...
20:03 < migurski> either URLs you go to, or everything on one page
20:03 < mvexel> tabs would be better in sync with the rest of the web site but I don't believe the number of options is big enought to warrant splitting it up visually like that
20:03 * mvexel opens his desk drawer and sees a lot of tabs
20:05 < migurski> my feeling is we're introducing new things, and should hold back the urge to categorize and isolate them behind deeper links if they're something we want people to pay attention to
20:05 < migurski> user pages in my experience are a dead zone right now
20:05 -!- apmon_ [~kai@ucb-np2-65.colorado.edu] has quit [Ping timeout: 480 seconds]
20:07 < migurski> I need to log off; good chatting with y'all
20:07 < zere> great, guys! i have to go now, but thanks for coming - hope to see you next week :-)
20:07 < migurski> need to figure out a way to deal with this monday 11am conflict I'm going to continue to have
20:08 < zere> do you want me to put change of time on the agenda?
20:08 < migurski> thank you zere!
20:08 < mvexel> I need to be off too - see you next week if not before then
20:08 < mvexel> I can do later but not earlier
20:08 < zere> i don't think anyone's particularly wedded to this hour. we could take a straw poll next week?
20:08 < migurski> I'm up for that
20:08 < mvexel> cool