Attendees
| IRC nick
|
Real name
|
| zere |
Matt Amos
|
| tomh |
Tom Hughes
|
| RichardF |
Richard Fairhurst
|
| emacsen |
Serge Wroclawski
|
| apmon |
Kai Krueger
|
| SteveSn_ |
Steve Singer
|
| iandees |
Ian Dees
|
Summary
- SteveSn_ looked through some of the tickets and found that many could be given one of the following keywords: gpx_traces, history, user_location, api_errors. This will make it easier to categorise the tickets.
- There was some discussion about the "black hole" nature of the trac system and whether it was the best method of reporting / curating bugs, including whether having a single responsible "bugmaster" would help. It was suggested that a ML be set up and trac notifications sent to it as an experiment to see if that works.
- The "new ticket" page was considered confusing, as many OSM-related projects such as JOSM and JXAPI are not tracked there. New language was put on that page to help make reporting bugs in the right place easier.
IRC Log
18:04 <@zere> minutes of the last meeting - take a look and if there's anything objectionable, let me know http://www.osmfoundation.org/wiki/Working_Group_Minutes/EWG_2011-08-29
18:05 <@zere> emacsen was around earlier, but i wasn't, so maybe he's assumed we're not doing the meeting today...
18:05 < stevensn> no objections
18:05 < apmon> no objections either
18:06 <@zere> we were all to look through trac and try to come up with some ideas for keywords, but i have to admit that i've been lazy and haven't done it. :-(
18:08 < TomH> indeed
18:08 < stevensn> I've looked at a random sampling of tickets, I saw groups related to: gpx traces, change sets/history, users in an area, error handling/making the API code more defensive against broken editors/people
18:10 <@zere> stevensn: great! thanks. that's a good place to start.
18:11 <@zere> open question: is it more useful to have a small number of very granular keywords, or be more detailed and have more keywords?
18:12 <@zere> i can see advantages to both ways of doing things. i guess it depends on whether keywords are useful to identify areas of code, or to thematically group stuff...
18:14 < TomH> you can always add both a coarse keyword and a fine one to the sae bug
18:15 <@zere> ok, so shall we start by adding the 4 that stevensn has identified, applying them to some tickets and iterating towards the "best" keyword set?
18:15 <@zere> i assume it's not too hard to add / edit the list of keywords?
18:17 < TomH> no idea
18:18 < stevensn> keywords are just a free form text field I think
18:18 <@zere> i thought TomH found that they had to be pre-defined in some trac config file?
18:19 < TomH> that was if you use the tag suggestion plugin
18:19 <@zere> oh, right. otherwise it's free-form. cool.
18:19 < TomH> you have to tell it what tags to suggest - it can't work it out from the database
18:21 <@zere> well, i'll try to do a go-through of trac (again). stevensn, TomH, everyone - if we could all have a short look at trac before the next meeting and start applying the keywords where they're appropriate?
18:21 < TomH> do we have a list somewhere of the keywords we're going to use?
18:21 <@zere> they presumably have to be single words, so gpx_traces, history, user_location, api_errors?
18:22 <@zere> stevensn: does that sound like a horrific oversimplification^W^Wreasonable list? ;-)
18:22 < stevensn> that sounds good
18:23 <@zere> awesome. and if we find things that aren't in those categories i guess we can discuss that next time.
18:23 < apmon> It might be good to also have a classification if it is a data oriented feature / issue, or a user oriented feature / issue
18:24 <@zere> broader than just api / web site?
18:24 <@zere> or would all api-related issues also be data-oriented issues?
18:25 -!- iandees [~iandees@c-75-72-171-38.hsd1.mn.comcast.net] has joined #osm-ewg
18:25 < stevensn> apmon: I am not sure what you mean by 'data-oriented'
18:27 <@zere> maybe he means anything that's not user-oriented? ;-)
18:27 < apmon> things that are about the actual osm data vs all the additional features of the website, like diaries, or friends, or configuration options...
18:28 < apmon> for example the request to proved the api output in different formats (json, xml pbf, amf...)
18:28 <@zere> so gpx traces and api errors would be data-oriented, and users-in-an-area would be user-oriented?
18:28 < apmon> although perhaps the component destinction api vs website would do for that
18:29 < apmon> yes something like that
18:30 <@zere> is the data/user distinction derivable from the keywords stevensn already identified? could we just ensure that all keywords fall into one category or other?
18:30 < stevensn> I'm not sure I see value in breaking things up that way. Even the bugs related to gpx traces might have UI components to them
18:30 < apmon> zere: I guess that would be sufficient
18:31 <@zere> we can put multiple keywords in there, if we want to make the distinction clearer, e.g: gpx_traces, website or something like that
18:32 < iandees> are we talking about the trac bugs?
18:32 <@zere> ok. let's all have a go at that, and report back next week on how it's going and suggestions for new/improved keywords.
18:32 <@zere> iandees: yeah, trying to get some structure to them. useful for identifying "starter" projects, perhaps.
18:33 < iandees> when I poked through there i got the impression that the components did a pretty good job of identifying where they "belonged"
18:34 < iandees> i did a query for all 1600 bugs and grouped them by component to get a fairly good idea of what was going on. there were a surprisingly high number of old (>2 years since last modification) bugs
18:34 < apmon> TomH: slightly off topic, but could you add trac components for mod_tile and osm2pgsql. I think they currently don't fit into any of the components
18:35 < iandees> apmon: +1 there were some osm2pgsql bugs strewn about in different categories
18:35 < TomH> apmon: well I need an owner for them
18:35 <@zere> the components refer pertty much to areas of code. i think the idea with keywords is to add a little more detail about the "purpose" of bugs/features.
18:35 < TomH> iandees: they are mostly in utils I think
18:35 < apmon> TomH: jburgess would likely be the best, but if he doesn't want to be the owner, I could do that too
18:35 < TomH> iandees: the old bugs are often enhancement reqs rather than true bugs
18:35 < iandees> also there were loots of Mapnik style change requests
18:35 <@zere> TomH: is there a list of owners for each of the components?
18:36 < TomH> not pubically
18:36 < TomH> publically even
18:37 <@zere> since emacsen isn't here, i'll present his idea for him - we were talking about this and he suggested we have a "bugmaster" for each project/component, listed publicly, as a point-of-contact and triager of incoming bugs. thoughts?
18:37 < iandees> i think that's what the component owner is
18:37 < apmon> can you have multiple owners?
18:38 <@zere> except that a component owner isn't really a point-of-contact if they're not listed anywhere publicly.
18:38 < TomH> so encouraging people to submit reports by emai rather than trac?
18:38 < TomH> apmon: I've created those components
18:38 < iandees> zere: they're point of contact in that when you file a bug against "their" component they get the bug
18:38 <@zere> not necessarily. but i'm not totally sure that having people put bugs/features directly into trac is the best way to manage things.
18:39 < apmon> TomH: thanks
18:39 <@zere> i mean, you have to have a certain level of technical skill to write a decent bug report.
18:40 <@zere> i was thinking that if we decouple trac from the reporting of issues/features then we have more flexibility and make sure that trac doesn't get full of things which aren't ever going to be done.
18:40 < stevensn> some projects have a -bugs mailing list for bug reports but if bug reports don't get transcribed into trac always they can get lost
18:40 <@zere> also, trac seems a particularly bad place to have a discussion about a ticket. but these are just my thoughts.
18:41 <@zere> stevensn: yeah, that's what i was thinking - it allows a discussion of a bug (in public) before it gets put into trac.
18:42 < stevensn> right now with trac anyone can open any idea as a bug and it takes an explicit effort to close it, with a mailing list it takes an explicit effort to accept it as a bug.
18:42 <@zere> so people who come and suggest things which are very complex or hard will at least get some feedback about it, rather than it disappearing into trac, or having a battle on the trac comments with people re-opening tickets and closing them again.
18:43 <@zere> stevensn: exactly. it's a pre-filter, if you like, to make sure that trac doesn't have a lot of noise in it.
18:44 <@zere> TomH: does this sound like a good idea to you? i mean, you end up doing a lot of the trac-farming / noise reduction already.
18:44 < iandees> lots of stuff on the mailing list ends up sying there
18:44 < iandees> s/s/d/
18:45 <@zere> yeah, so that's where a "bugmaster" or component owner comes in - it would be their choice/decision to bring stuff into trac.
18:45 < TomH> well not really, unless you're somehow going to lock trac down
18:46 <@zere> not lock it down necessarily, but not present it as "the place to report bugs" any more.
18:46 < TomH> and then when the god^Wbugmaster decides to accept a bug how does he raise it? it wouldn't be possible for the owner to be set right
18:46 < stevensn> I recall filing bugs against some projects where they went to UNVERIFIED and sat there until a responsible person changed the bug state
18:47 < TomH> frankly it sounds to me that instead of a trac ticket with a couple of no, bugger off responses we'll instead have a two week, 300 message mailing list thread arguing about it
18:48 <@zere> sure. but at least the 300 message ML post will explain the reasoning behind the decision and be a precedent to point at the next time it happens.
18:48 <@zere> or am i being very idealistic there?
18:49 < TomH> dunno, but I'll have tuned out by about message ten ;-)
18:50 <@zere> stevensn: the problem i see with that is that it has the same "black hole" nature as trac tickets already do. a ticket might sit "unverified" for years (as, afaik, some java ones did in sun's bug-tracker)
18:50 < apmon> I am not sure a ML will necessarily be that much better than trac to be honest
18:50 < stevensn> zere: is sending a message to an ML that gets ignored any better?
18:51 < stevensn> at least with trac it is easier to get a list of issues in the past month that haven't yet been looked at
18:52 <@zere> i'm trying to figure out if we can have some system whereby people do report bugs, and don't get put off by the possibility of a silent rejection. that they want to report bugs. and if they report a bug that's not going to be done, or misses the point, or is crazy, then they get an explanation.
18:52 <@zere> i don't know if some such system exists. are we using it already?
18:52 < apmon> Do we have a feel of who would like to report bugs but gets putt off by trac?
18:53 < stevensn> should the bug tracker be only for bugs and not feature requests?
18:53 <@zere> there's something like 2-3 tickets a fortnight raised against website/api components (iirc) and i can't believe that that's because there aren't any issues! so something must be putting them off, right?
18:54 < apmon> zere: Perhaps a solution would be to do what potlatch does. Send any updates to trac tickets to a component specific ML
18:54 < apmon> that way more people would get notification of updates / new tickets and could respond appropriately
18:54 <@zere> that might work. TomH: what do you think?
18:56 < TomH> fine by me
18:56 < RichardF> it seems to work well IMX. and you occasionally get ml lurkers who supply patches
18:56 <@zere> RichardF: speaking of lurkers.... ;-)
18:57 < RichardF> heehee
18:58 <@zere> TomH: could i ask you to set up a rails-dev ML and send trac activity for website/api components (and whatever else you think is appropriate) there?
18:58 <@zere> please?
18:59 < TomH> sure
18:59 <@zere> thanks :-)
18:59 < iandees> sounds like a good request for a bug :)
18:59 <@zere> does anyone want to discuss anything else?
19:00 <@zere> i had something, but it's probably too long to talk about this time...
19:00 < iandees> when going over the bugs i got the distinct feeling that i didn't really know enough to be able to close/comment on the bugs
19:00 < iandees> even though i've been in the project for ~5 years
19:01 <@zere> if any of us feel like that, then we can always raise it here, or on dev@ or rails-dev@.
19:01 < apmon> iandees: I kind of felt similar.
19:01 < iandees> maybe it's that i knew *too much* that those 2+ year old bugs are really enhancements and could possibly be done ... :)
19:02 <@zere> at some point we need to look at those - is the only reason that they haven't been done yet that they're too hard? too vague? not interestign enough?
19:03 < TomH> list created
19:03 <@zere> and then figure out whether it's worth doing something to try and fix that...
19:03 <@zere> TomH: awesome, thanks :-)
19:04 < iandees> here's the query i used ... http://trac.openstreetmap.org/query?status=accepted&status=assigned&status=new&status=reopened&group=component&max=1108&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=time&col=changetime&order=priority
19:04 < iandees> here's an example of one i didn't really know what to do with: http://trac.openstreetmap.org/ticket/17
19:04 < iandees> it's older than dirt
19:04 < iandees> but possibly a good idea? or maybe not.
19:06 <@zere> it probably is a good idea... and probably not too hard. (imho)
19:07 < apmon> does it save server resources, or just bandwidth?
19:07 < RichardF> some stuff is just out-of-date - I'm not sure there's a whole lot of point keeping any potlatch 1 tickets
19:08 < iandees> there's a dozen or so xapi tickets, too
19:08 <@zere> no, i think most of the queries probably wouldn't be sped up by a timestamp filter. i could be wrong though
19:08 < TomH> the xapi tickets go to 80n
19:08 < TomH> so are implicitly against "old" xapi
19:08 <@zere> iandees: fancy taking over the xapi component? ;-)
19:08 < iandees> the bug list for the jxapi component is elsewhere ;)
19:09 < iandees> but my point was that the xapi code isn't being used (unless we want to make a fosm component :) )
19:09 < TomH> ha 80n will probably ask for that soon...
19:10 <@zere> is it worth transferring the useful "old" xapi tickets to github and then dropping the old component completely?
19:11 < iandees> do we have somewhere to point people to the right spot for filing bugs?
19:11 < iandees> josm -> josm.osm.de, jxapi -> github, etc.
19:11 <@zere> i don't think so.
19:12 <@zere> hence why i thought it might be a good idea to decouple the filing of bugs from the reporting...
19:12 < stevensn> we should list that (the URL for josm, jxapi etc.. ) in the text on trac when you click "new ticket"
19:12 < TomH> only in as much as the new ticket page tries to tell people where to go for josm
19:12 < stevensn> expand the list from just JOSM to cover other things of importance
19:13 < TomH> http://trac.openstreetmap.org/newticket is the pag
19:13 < TomH> shout if you have specific suggestions for changes
19:15 < iandees> hmm... not sure if i have any good ideas other than "list all the projects and their bug trackers"
19:15 < iandees> but that's not very useful
19:16 <@zere> replace the parenthetical comment with "Trackers for some components are elsewhere. Please report bugs for the following projects on their specific pages: <ul><li>JOSM: Please use JOSM trac.</li><li>JXAPI: Please use the JXAPI github page</li></ul>"?
19:16 <@zere> with appropriate linkage, of course.
19:17 <@zere> do you need a github account to create tickets there?
19:17 < TomH> that was my point really - somebody needs to give me a url ;-)
19:18 < iandees> is there a wiki page that points to the /newticket trac page? could we have a page that says "make suggestions for our software here!" and lists the software with links to /newticket?component=api, link to github, etc.
19:18 <@zere> https://github.com/iandees/xapi-servlet/issues (iandees?)
19:19 < iandees> yea, thanks zere. i was too busy typing :)
19:19 < RichardF> zere: Friendlier/more concises language: "This is the bug-tracker for the main OpenStreetMap project; for other projects, see the sites for <a href="...">JOSM</a>, <a href="...">JXAPI</a> [etc.]"
19:20 < RichardF> s/concises/concise/ , obviously
19:21 <@zere> i thought having the <ul> would make it more likely that people would actually look at it, rather than just skim it if it's inline ;-)
19:23 <@zere> it looks like we're more-or-less finished with the meeting. thanks to everyone for coming! see you next week :-)