| IRC nick
|| Real name
|| Kai Krueger
|| Paweł Paprota
|| Tom Hughes
|| Matt Amos
- Sorting out (rough) goals for 2013:
- EWG is a place for technical discussion
- better documentation
- better availability of issue-tracker information
18:03:40 <zere> minutes of the last meeting http://www.osmfoundation.org/wiki/Working_Group_Minutes/EWG_2013-02-11
18:03:58 <zere> please let me know if there's anything which needs correcting in them.
18:04:35 <zere> today i'd like to try and pin down some sort of role in 2013 for EWG
18:05:12 <zere> i think there are probably many different opinions on this, so it would be good to hear them and see what we can all agree upon
18:06:21 <zere> i think last week's run-through of issues in the bugs/notes branch was very productive. so that encourages me that EWG meetings are good for specific technical discussions
18:07:23 <zere> perhaps people could chime in with "i think EWG meetings are a good place for ..." suggestions?
18:16:46 <zere> TomH, apmon, ppawel, pnorman - any interest in having a go at the above, or shall i move on?
18:17:37 <TomH> don't think I have any particular ideas on the subject
18:17:56 <apmon> zere: Do you have more thoughts on the topic?
18:19:07 <ppawel> zere, yeah technical discussions are good but it seems to me that they run counter to the EWG mission - which I guess is 'helping develop development' not 'helping develop'
18:20:17 <ppawel> I think the discussions we had about documentation, 'junior jobs' and such were more very good
18:20:49 <zere> i find the whole thing somewhat confusing. some times we have very good discussions here that are helpful, and other times this channel stays pretty silent. on the assumption that when it stays silent, that's an activity that people aren't really interested in, i'm trying to figure out what the meetings should actually be about.
18:21:56 <ppawel> I guess it's hard to keep the discussion going with only 3-5 people attending
18:22:00 <zere> given that, on the whole, me talking to an empty channel isn't a great use of anyone's time, i'm trying to figure out what would be a good use of approximately 1h of all of our time.
18:22:38 <apmon> I kind of agree with ppawel that the idea behind EWG was to identify what resources OSMF could provide to make it easier for others to start developing. On the other hand, if there are helpful technical discussions, it wouldn't be good not to have them
18:23:30 <zere> if we took this time - about 3-5 man-hours as ppawel says - and just used it for coding, would that be an improvement?
18:24:29 <apmon> I suspect it isn't actually 3 - 5 man hours, as people are probably only partly paying attention to the channel.
18:24:37 <zere> gee, thanks ;-)
18:25:20 <ppawel> I personally liked it when there were specific action items. at least then there's some kind of buy-in from the volunteer to perform given action
18:26:30 <ppawel> another question is what should these items be about... I thought a bit about people who were potential contributors but then somehow faded away and didn't do anything (for the rails port)
18:26:42 <ppawel> it would be nice to find out why they didn't end up being active coders
18:27:12 <zere> as apmon and ppawel have said, there's a couple of roles that EWG has included from the beginning: bringing OSMF resources to bear, and helping conduct technical discussions. the latter is pretty easy, and we can be very flexible about bringing stuff up. the former is more difficult, as we'd need to make at least a rough plan.
18:28:35 <zere> ppawel: yeah, specific actions are helpful. but it's been a bit of a struggle to put together any sort of plan for 2013, from which most of those actions would probably derive.
18:29:21 <apmon> On the technical side, there is still the top ten tasks
18:30:06 <apmon> given that in 2012 we hardly managed to achieve any of them, I am not sure our current approach worked too well
18:32:23 <zere> we've had a few discussions about that in previous meetings - whether those tasks were of the right granularity, whether we needed some other way of setting "direction" for the year.
18:34:44 <apmon> Well, smaller granularity tasks seemed to have worked well. Looking at the git log of the rails_port, it has been reasonably active overall
18:35:29 <ppawel> hmm, I'm just thinking about the plan and I really have no idea how to approach this.. I guess we can set another couple of specific goals (TTTs) but maybe try another approach, like focusing on documentation instead of adding new functionality as part of EWG.. I've found in the last weeks that even public API is not fully documented
18:36:01 <ppawel> the architecture/systems landscape diagram still needs replacing from the old "Develop" page (now on Components page)
18:36:07 <zere> right. i think we all agreed that smaller (issue-sized) tasks were better to show to get people started
18:36:26 <ppawel> judging from a couple of posts to dev@ it looks like some people can't get their head around what's what
18:36:42 <ppawel> maybe that's the barrier we should try to lower..
18:36:55 <zere> ok, so rather than TTTs, we could just expose project bug-trackers like we talked about, and put more of our collective effort towards documentation this year?
18:38:00 <ppawel> it's just a thought... it seems that when it comes to TTTs they go their own way anyway, it doesn't seem like EWG efforts affected those too much (altohugh I did join only late last year so correct me if I'm wrong)
18:38:36 <zere> definitely not 100% effective, we can be sure of that ;-)
18:39:33 <zere> apmon, TomH: do you think that a group effort to improve documentation this year is worthwhile?
18:41:00 <apmon> One issue with bug trackers is that there are often now multiple per project, which makes following them confusing
18:41:30 <ppawel> yeah definitely +1 to apmon... one big goal could be sorting out (whatever that means) the bugtracking situation
18:42:02 <apmon> e.g. there is trac, there is the github "openstreetmap" issue tracker and then some issues are noted against the individual peoples forkes
18:42:13 <zere> are there such things as meta-bugtrackers? bug aggregators? as a read-only interface, of course.
18:42:42 <apmon> For the rails_port, probably the rails-dev mailing list has achieved somewhat of a meta-bugtracker
18:42:42 <zere> presumably almost all bug trackers can present the list of bugs as an RSS feed
18:43:00 <apmon> as the various bug trackers do all email new comments and issues out to rails-dev
18:43:47 <apmon> perhaps it would be good to set up such a system for some of the other projects as well?
18:44:17 <zere> the issues against individual forks go there too?
18:45:01 <ppawel> I think this is at least partly in place (eg. nominatim bugs go to geocoding@ list etc)
18:45:24 <apmon> not sure about that, but at least trac and the main github one goes there. And it could possibly be setup such that TomH's branch issues go there too
18:46:02 <apmon> Perhaps we should set up a rendering-dev list as well, to push the mod_tile, renderd, tirex bugs to?
18:46:42 <zere> pretty sure that would be easy to do, yeah.
18:46:59 <zere> if it's helping for rails_port, i don't see why not
18:47:32 <apmon> I do have the impression it was useful for the rails_port.
18:47:44 <zere> i guess the only problem with that method is that it helps existing devs a lot, but isn't as accessible for someone looking for the first time.
18:48:39 <apmon> And I hope it would be helpful to keep track of the rendering stack bugs. e.g. I check the bug trackers far too seldom, so getting email reminders might be good to deal with them in a timely mannor.
18:50:32 <zere> ok, so three topics i'm seeing here are: 1) place for technical discussion, 2) better documentation, and 3) better availability of issue-tracker information
18:50:58 <zere> are they worthy (rough) goals for 2013?
18:52:25 <apmon> seem reasonable
18:55:18 <zere> perhaps we can try and work out what that would actually mean next week?
18:55:36 <zere> in the meantime, is there any other business?
18:55:40 <zere> #topic AoB
18:57:28 <ppawel> those goals sound good..
18:59:33 <zere> great! :-)
19:00:25 <zere> i guess there's no other business. so let's finish the meeting (on time!). thanks to everyone for their time & hope to see you next week.