2013.03.28 Weekly Check in

• 13:35 <demory> hey grant_h. we expecting Frank to join today?
• 13:36 <grant_h> No, he's on spring break w/ his family
• 13:36 <demory> ah, ok
• 13:37 <demory> well, i can give a quick update on what i've been working on
• 13:38 <grant_h> sounds good
• 13:38 <demory> so, one of my things for this week was to ticket up the various routing anomalies you all reported a while back
• 13:38 <demory> thing is, i can't seem to recreate them in a recent pull of master
• 13:39 <demory> (recent as in, the current last commit)
• 13:39 <demory> which leads me to wonder if maybe they've been resolved by the most recent work
• 13:39 <demory> i also can't recreate #945 on master, the transfer center bug
• 13:39 <nfn_> abyrd, i know that OTP uses Dijkstra and A* algorithms. I still doesnt see the code
• 13:40 <demory> i.e. it's doing what it's supposed to
• 13:40 <grant_h> hmm, the instance that Frank was testing on updates daily from master, but its been a few weeks since he documented those
• 13:41 <demory> yeah, i wanted to ask how recently he'd tried them against master
• 13:41 <demory> there have been a lot of routing-related commits in the last week or so
• 13:42 <abyrd> demory, thanks for trying to reproduce those bugs
• 13:43 <demory> ok, so the maps5.trimet.org instance updates from master daily?
• 13:43 <abyrd> interesting that they have been resolved... there were a couple egregious bugs fixed recently but I didn't imagine them causing the problems that were described
• 13:43 <demory> well let me double check that i haven't done something wrong on my end
• 13:44 <grant_h> demory: one of the instances we use for testing does
• 13:44 <abyrd> nfn_, the key question is how you are going to use users' evaluation of a full itinerary to affect routing calculations. that's not an obvious problem to solve.
• 13:45 <mattwigway> With regards to routing in Analyst, I'd also mention issue 990
• 13:45 <mattwigway> I'm not sure how soon I'll be able to work on it, but it's something to be aware of.
• 13:47 <nfn_> abyrd, the user classify the segments of an itinerary between 1(good) and 5(bad) for example. Then the system can use this rates to return the shortest path.. right?
• 13:50 <demory> so, i will keep trying to reproduce those routing bugs. on the front-end side, I'm working on an improved stop list / timetable viewer for trips. that will require some modifications to the TransitIndex API
• 13:50 <demory> variantForTrip seems to be completely broken in master right now, btw
• 13:50 <abyrd> mattwigway, thanks for mentioning and ticketing that. no pressure to get it fixed right away as long as we know it needs some work.
• 13:51 <demory> so i'm looking into that. eventually i want to add names to the stop info that's returned (currently it's just the id)
• 13:51 <abyrd> nfn_, but the quality of a segment of an itinerary is context-dependent. how could you use that information to influence completely different searches?
• 13:52 <nfn_> what do you mean with context-dependent?
• 13:53 <abyrd> demory, I've talked to several people who would like to see the transit data API grow a bit so they can use it instead of OBA in simple cases
• 13:53 <abyrd> so any improvements there are welcome
• 13:54 <abyrd> nfn_, I mean that the usefulness or quality of a sub-part of an itinerary depends entirely on which itinerary you are looking at. Just because a certain route is a bad choice for a given itinerary does not mean it is bad in all other itineraries.
• 13:54 <demory> yeah, i hear the same thing. at least for accessing basic static data
• 13:54 <abyrd> It is usually not the route/segment/edge itself which is bad, but some costing parameters that misrepresent the user's decision making behavior
• 13:55 <abyrd> I hear the same thing for real-time data as well :)
• 13:55 <grant_h> demory: we usually run a suite of tests each night on our instance that uses master and some of them were failing due to #945. It looks like test actually haven't run since late February (although I sometimes have issues with getting the test results page and cacheing)
• 13:56 <grant_h> I'll try to see if I can launch the tests manually and check if they're continuing to fail
• 13:56 <grant_h> with the new code
• 13:56 <demory> ok, thanks
• 13:58 <demory> i'll do some more experimenting on my end too
• 13:58 <demory> anything else for today?
• 13:58 <nfn_> abyrd, can you indicate a concrete situation where that's happen?
• 13:58 <mattwigway> should we talk about the PLC/Software Freedom Conservancy proceeding
• 13:58 <mattwigway> er, proceedings?
• 14:04 <abyrd> mattwigway, sure we need to finalize that
• 14:05 <abyrd> I am going to send out a proposed agreement to the list tonight since discussion has died down a bit
• 14:05 <mattwigway> I'd be in favor of the simple self-perpetuating committe
• 14:05 <mattwigway> er, committee
• 14:05 <abyrd> I was hoping to hear some support on the list for the point of view I expressed but no such luck
• 14:05 <mattwigway> which was that, sorry?
• 14:05 <abyrd> Yes, I think we should just do the simple self-perpetuating committee
• 14:05 <abyrd> with no limitations on who can participate
• 14:06 <abyrd> but with the understanding that this is a voting body that will influence how our IP is managed
• 14:06 <abyrd> and therefore should be composed of people who have had a stake in creating the IP
• 14:06 <mattwigway> right, you and David convinced me that we should have a minimum of requirements and that it should be primarily composed of developers
• 14:06 <mattwigway> (since it is an IP body)
• 14:06 <abyrd> developers, but also representatives of anyone who has invested time, money, or intellectually in the project
• 14:07 <abyrd> who are pretty much all devs right now
• 14:07 <mattwigway> although I'm in favor of no restrictions on membership per se, allowing anyone who has a role (as determined by the committee) to participate
• 14:07 <mattwigway> precisely what you said
• 14:07 <abyrd> I also agree with all the concerns about documentation and ease of use
• 14:07 <mattwigway> So I think SFC's first example paragraph is appropriate
• 14:08 <mattwigway> I agree with y'all that documentation/ease of use is a separate issue, though
• 14:08 <abyrd> but I think we should avoid the proliferation of "committees" and such bureaucratic structures
• 14:08 <abyrd> I am not against consultation with end users taking a more permanent form
• 14:08 <mattwigway> +1 on that
• 14:09 <abyrd> but these complaints are just surfacing now, with no attempt made yet to solve them in the "normal" manner
• 14:09 <abyrd> i.e. just participating in the collaborative creation process
• 14:09 <demory> abyrd, so would the initial composition of the PLC be the list you proposed last week?
• 14:09 <abyrd> before making committees we should first discuss issues on the mailing list,
• 14:10 <mattwigway> agreed, abyrd
• 14:10 <abyrd> and those who have had difficulties and have apparently made lots of notes can pass them on
• 14:10 <abyrd> we can talk by email or telephone with them and work together on the documentation
• 14:10 <mattwigway> incidentally, what's the time commitment of being a PLC member?
• 14:11 <abyrd> I see no need for a formal process but if people like to put a name on things we'll call it a consultation process and ask for input regularly on the list
• 14:11 <abyrd> reminding users that they are welcome to contribute
• 14:11 <abyrd> mattwigway, I think the time commitment is nothing more than voting when there's something to vote on
• 14:12 <mattwigway> ok, thanks
• 14:12 <abyrd> if all goes well, that should be quite rare
• 14:12 <abyrd> even this PLC is a formality -- things have funcitoned without it, but because OTP will basically become a division of SFC, we need a formal procedure for representing that division to its "parent company"
• 14:13 <abyrd> so it goes in writing...
• 14:14 <abyrd> nfn_, I was saying that this is always the case. people's judgement that a route is "bad" may have nothing to do with the GTFS data, and even if it did you wouldn't want to penalize routes because they happened to show up in what someone considers a bad trip plan.
• 14:18 <abyrd> nfn_, often routing problems involve a lot of human debugging to understand. the most useful thing for us would be a feedback feature that allows uers to indicate only when they think a route is bad
• 14:19 <abyrd> and then stores all the characteristics of the trip plan so a developer can dig into it
• 14:19 <abyrd> demory, yes I propose that list from last week for the PLC and also as the signatories
• 14:20 <abyrd> I will email everyone on the list and see if they want to join
• 14:20 <abyrd> mattwigway, I presume you will be both a signatory of the agreement and a PLC member?
• 14:20 <mattwigway> Yes.
• 14:20 <demory> ok, great. thanks for driving the discussion on this
• 14:20 <mattwigway> Thanks!