- 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.
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 [~firstname.lastname@example.org] 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 :-)