rama: Hi All, Welcome to our first IRC Chat
rama: We are waiting for Pascale and Val
J-Lo: val's all set up - she should be on any minute
rama: I sent out an Agenda last week. We will go through items from that list. Is that okay?
goHitzter4929: k pascale has joined the channel
rama: August release is first
rama: welcome Pascale
rama: Val just pointed out a bug in show siblings in the toy server.
sjcarbon: is there a url for that?
goHitzter4929: her bug report was a little confusing - I thought she meant in the production server until I looked at the URLS
rama: she sent an email to the WG mailing list.
goHitzter4929: dev server
rama: I was also confused. But, production is working fine as far as I can tell. She says that she saw what she expected in production.
rama: please query for Tea1 in toy, click on the term name, select 'term siblings' on the term details page.
sshu: do we want to sort this out here?
rama: we don't have to sort this out here. We can test it over email.
rama: Otherwise, I don't think there are any bugs i think. please correct me if I am wrong.
goHitzter4929: looks like it's not showing part_of siblings
rama: We need input on several text changes for GOst that Eurie, Pascale and I suggested. Can you all please take a look and give feedback?
eurie: Is there a compiled list somewhere?
pascale: that would help I agree
rama: Regarding the other item that pascale brought up- displaying 17 gene_products instead of just 17 next to the term, since this is was not scheduled for the august release, I would like to have more discussion on this
rama: I will compile a list and send it around (text edits I mean)
pascale: thanks J-Lo raises her hand
J-Lo: i just got an email off Amelia...
sshu: get a list and finalize the solution, and I will imlement them. we need to roll out august release soon.
goHitzter4929: I don't think adding text to the # of gene products is really the ideal solution
rama: going back to 17 gene_products (i did not finish my sentence).... can we move it to the next release?
rama: okay, any other outstanding issues for August release?
goHitzter4929: oh, you meant discussion on when to release it. probably later is good then
rama: yes, we will make sure we all agree on mouse over vs explicitly saying 17 gene products etc and do it for the next release.
rama: Okay, I want to move on. Any thing else on August release
pascale: I don't think so
rama: Okay, send email if you notice bugs. I am moving to item 2.1 on our agenda
rama: regular amiGO chats- will the first and third Tuesday at 930 AM (PT) work for everyone?
pascale: works for me
kchris: fine for me
eurie: fine, as long as we can try keep it to an hour or so
rama: Okay, we will do IRC and switch to phone if we have a need to hear eachother's voice
goHitzter4932: seems like a good place to collect things like text edits for GOst
rama: How do we want to use it? Right now people are posting on the email and on the WIKI. do we want to continue that mode
J-Lo: I prefer it when things are summarized on the wiki, so it's easy to refer to
sshu: agree, send out an email to remind people of wiki update
goHitzter4932: wiki doesn't usually have "instant gratification" of email
rama: I prefer that summarizing on Wiki too
eurie: Yeah, I think I like the summary on the wiki. At any stage of the conversation. PUtting the text edits is a good idea.
sjcarbon: i think consensus items are good for the wiki
rama: looks like we have a consensus...we will send comments on mock-ups etc on email, and one of us will summarize on the Wiki
goHitzter4932: right, so example email "is blah important enough to go in the wiki"?
goHitzter4932: Well, I think it's fine to directly comment on something IN the wiki
pascale: does it matter? we can add and remove any wiki page easily
eurie: The difficult comes in trying to follow a conversation between email and wiki
pascale: I liked having the 'discussion' on the wiki also
pascale: and we can summarize on the main pae
sjcarbon: i'd prefer if the wiki was more for reference, not things still in the air
eurie: uh, what's the difference between the "talk" pages and the others?
rama: i agree with Seth
goHitzter4932: maybe suggest that email = informal discussion, anything "official" should be put on (or added to) the wiki
eurie: could we use the "talk" for ongoing and the main pages for summaries/consensus decisions.
rama: and with Ben
J-Lo: I'm with Pascale and Eurie
gwg: apologies for being so late... connection problems!
rama: I haven't used 'talk' on the wiki.
goHitzter4932: I don't know the the talk pages either
pascale: is 'talk' the same as 'discussion'?
sjcarbon: i'm a bit worried about having too many lines of communication--why is email insufficient?
rama: we have to figure it out.
J-Lo: it's hard to refer back to email threads
eurie: oh, i got it - I was going to the "talk" via the emails I was receiving from wiki and didn't know how to get there from the main page. never mind...
pascale: I agree with Jane about threads
eurie: now that my confusion is cleared up, I'm on the same page as seth and ben and rama.
goHitzter4932: if you are strict about it - discussions on email, summaries on wiki then the page "owner" has to be vigilant about keeping it up to date.
eurie: I think at any point in the email conversation, someone can regroup and summarize on the wiki.
gwg: I prefer the wiki because you've got all the points in one place, and they're not hidden within emails
rama: can wiki thread?
gwg: you can do the equivalent, which is what the discussion page does
goHitzter4932: rama, I think there's no need to "thread" wiki because you would be modifiying a specific page.
gwg: I moved some of the comments from emails and the comments on the 'article' page to the discussion page
pascale: this allows us to have both the full discussion and the summary at the same location
rama: i guess, we all have to get this into our routing. Check the WIki and make comments
rama: Thanks Amelia. I was just wondering about all my comments on the mock ups.
gwg: don't worry, I didn't delete them. only the ones I didn't like
J-Lo: that looks really good - perhaps if we do have email discussions, we can nominate someone to move it to the wiki like this each time...
rama: I meant we should incorporate checking the WIKI into our routine. We all check email everyday and will surely read the comments.
sshu: you can set watch on wiki for any page, I think.
rama: yes you can set a watch on the wiki.
J-Lo: cool - so it emails you when someone makes a change?
eurie: what about the issue of deleting previously stated comments? Honestly, I don't get to everything right away - and I like reading the previous conversations as to not rehash something that's already been stated.
eurie: No, it only emails you the first time someone makes a change. it doesn't email if you haven't looked at the page & 5 people have edited.
gwg: that wouldn't be a problem though - why would anyone delete someone else's comments?
eurie: in that sense, you don't get an idea of how "hot" a discussion topic is.
rama: good point eurie
pascale: but we could email the AmiGO list to let others know we have edited the wiki
sjcarbon: why not just email the AMiGO list?
sjcarbon: wiki for "official" stuff
pascale: to save the entire thread nicely
sjcarbon: threaded email reader?
gwg: you still have to wade through the email to find the relevant points, though
kchris: some threads get really complicated, such that reading the whole thread becomes confusing
kchris: maybe it's easier to have the discussion on email, and then just put the summary on the wiki...
goHitzter4932: I think we are just going to have to muddle along for a while to find the balancing between emailing and wiki conversation val has joined the channel
pascale: we can also send a summary to the email list gwg agrees with ben
J-Lo: yes - perhaps we should revisit this as we get more experience using the wiki...
eurie: right, at any given point in the email thread, someone can summarize and put salient points on the wiki. then we can all refer back to the wiki
kchris: should we move on to the next agenda item then...
val: sorry, it just took me 2 .5 hours to travel 12 miles on public transport.
rama: okay, for now we will discuss over the mailing list, and one of us will summarize for WIKI
rama: moving on to 2.4 and 2.5
rama: any questions on that?
rama: They are just Standard operating procedures.
rama: I am moving on to item 3
gwg: I think that rather than having "silence implies assent", we should say that if you don't respond within a certain time, you forfeit your right to respond
gwg: like we do on the oboedit working group
goHitzter4932: not to be pendantic, but you must assume silence implies agreement after some period of time. You are not going to hold off some small but important change just because one of the 10 of us did not send an email saying "sounds good"
rama: got it amelia. we will give time to respond.
rama: Ben, i agree
kchris: on the OE WG, we agree to specific dates by which point if you haven't commented, too bad
eurie: yeah, i agree. i think we'll just need to be explicit about time frames and dates
rama: yes, in the future, we will give a time frame to respond.
rama: okay, moving on to 3.1
kchris: People can also say they need more time and if the majority of the group agrees, then extend the deadline
rama: Karen, yes, good point.
gwg: good point Karen
goHitzter4932: by commenting that you need more time, then you are not being silent
kchris: main point was that the deadlines can be changed if group agrees
rama: I broke down the issue with IEAs into 3 separate items. do you think this is reasonable?
goHitzter4932: 3.1 and 3.2 are very closely related.
rama: Ben, yes.
eurie: In some sense. I see 3.1 as more of an interface layout issue.
kchris: I agree with Eurie on 3.1
val: yes interface, efficiency, time schedule seems reasonable way to break these down Rama
eurie: We want to make sure that we do the redesign of the pages making sure the page is scalable to view 1000s of annotations.
eurie: Just so we don't have to redesign pages again when we can add ieas
goHitzter4932: ... in a reasonable amount of time
rama: which brings us to the mockups
goHitzter4932: it doesn't matter if you interface looks good if no one can see it because the code takes 15 minutes to execute
goHitzter4932: any way - I am being silly here, the points are all relevant/
eurie: Yes, I agree
eurie: That's why 3.2 is a related but still separate issue
gwg: I think the most important thing here is whether the database people (e.g. Mike C.) are going to be happy loading the annotations
gwg: he seemed a little cautious about it...
goHitzter4932: we are working on the loading issue.
kchris: I think the interface ideas we've been talking about are basically to have the default load fewer things, so that the interface won't take stupid amounts of time to load
goHitzter4932: best news so far: new machines might give us a factor of 2 (yay intel)
kchris: Regarding having IEA's only loaded once a month, or something not so frequent, that sounds fine
goHitzter4932: refactoring the code to make it more effecient is a non-trivial process, on the order of 6-8 months for ~1 programmer
kchris: GOA only releases something like monthly anyway
val: I would be happy if the IEAs were only loaded once a month. It would be good though if this always happened just after the GOA release cycle which is monthly (i think?) so we don't end up waiting 2 monthe for new GOA data
gwg: how many programmers would be working on the code?
rama: Amelia, we should first make sure the interface can display 50K annotations. Loading can be worked on independently
sshu: good point ben.
goHitzter4932: our goal is to get the currently monthly loads -> weekly
J-Lo: will the manual annotations still be uploaded weekly though?
sshu: IEA will be a tough issue, it just have too many data. software eng can some improvement to a point.
kchris: weekly loads of IEAs, or weekly loads of the currently loaded data?
rama: yes. ontologies are loaded everynight, annotations (manual) are loaded everyweek, IEAs once a month
goHitzter4932: they are currently loaded every 3 days
val: would it be possible to load manual data weekly and IEA monthly, or does all the data need to be updated every update cycle?
J-Lo: I think they're saying manual weekly, IEAs monthly Val
val: so if the GOA data is only released once a month, is there any point in making this update cycle more frequenct?
goHitzter4932: manual is currently updated faster than 1/week
kchris: I agree with Val that if GOA is only releasing monthly, our goal to load IEAs for AmiGO doesn't need to be any more frequent
val: sorry I thought the question was could we live with monthly update cycle for IEAs, I could, there doesn't seem any point making it more frequenct as the data won't change that much
goHitzter4932: I am not sure how frequently non GOA IEAs are submitted
goHitzter4932: mike might know
kchris: probably less often than GOA
val: We are almost certain that GOA aims for a monthly release cycle, sometimes it goes longer.
eurie: i think that a similar sentiment is being expressed by the group: manually curated data should be uploaded into AmiGO on a more regular basis than IEA annotations. And that we are ok with IEAs being loaded on a less frequent basis.
kchris: sounds fine to me
pascale: me too
gwg: sounds sensible to me
goHitzter4932: there will be some engineering involved there...
val: and me
rama: moving on to 3.1 again
goHitzter4932: because (I think) currently, amigo uses a single instance of a mysql database "go-lite" (manual annotations, loaded ~3/times week)
goHitzter4932: it might be tricky to switch to a different database ("gofull") which contains IEAs... or otherwise modify the loading so that only IEAs are added every month.
goHitzter4932: All I am trying to say is that we have to account for the time it will take to work this out. Compare to a simplier solution of loading everything all at once as often as possible.
eurie: re: engineering - that's ok. what we are doing now is setting a target goal. we can adjust as needed. All this development needs to be a conversation between curators and developers and database. the IEA stuff is a big deal (in our resources and user demand) so we should start planning for it.
val: is it possible to purge the non-IEAs and only load the new manual data when a full IEA update isn't required if loading IEs is the time consuming step?
eurie: That's all this is right now - having a discussion, see what the consensus is from the group, and then make a more concrete plan.
eurie: va;. O dpm
kchris: I think we're getting into implementation issues that the programmers should decide, for now the agreement we've come to is that we don't mind if it is only possible to load IEAs 1x per month
eurie: oops - val, I don't think we need to go into implementation details here. Ben, Shu, Chris, Seth, and SGD programmers can come up with a proposal andn then we can go from there
rama: I agree...
goHitzter4932: val - [reply deleted]
kchris: back to 3.1 then...
rama: Interface changes//
rama: Can we talk about mockups?
rama: The front page- GOOGle like look?
rama: should we allow users to type in a term name or gene product name and on the results page list how many hits in each different categories (Eurie's suggestion)
gwg: I agree with the comments various people made about having some explanatory text
gwg: even if it's just a sentence
rama: I agree with that as well.
gwg: I wasn't creative enough to think of one myself, that's all!
eurie: THe submit query button gets lost. Can we move that right of the search box
goHitzter4932: doesn't everyone just hit <enter> anyway?
gwg: I used google for my prototype - they have the search button underneath...
rama: Ben, people are used to seeing a Submit button.
kchris: no, I've seen lots of people use the mouse to click the button
pascale: right, I dont think we can assume whether people hit submit or return
rama: yeah, but GOOGLE doesn't have the radio buttons underneath. Should we try moving the radio buttons down or up?
goHitzter4932: j/k but it's just that the button graphic needs some tweaking. If you are going to mimic google, may as well put the button in the same place
gwg: we need an 'I feel lucky' button too, then
kchris: perhaps not
J-Lo: perhaps the button just needs to be bigger?
goHitzter4932: graphic needs shading to look more like a button
gwg: maybe if it said "submit query"?
eurie: I agree with a sentence of explanation. How about "Enter a biological function, process, or localization (e.g. alcohol dehydrogenase, DNA repair, mitochondrion) or a gene name (e.g. ACT1, okra, unc81)
pascale: maybe more centered (it seems just a bit too high)
gwg: ben - the graphic is generated by the browser
goHitzter4932: this is going to be a long meeting...
rama: I thought somebody mentioned removing the radio button completely from the front page.
gwg: I have to go at 70 (20 mins)
goHitzter4932: amelia - you can change this (by hook or crook)
gwg: pascale - I can easily shift it down
gwg: ben - yup, I can do if people want
J-Lo: i think yes...
rama: we do want the radio button options on the front page? somebody mentioned that users would then have to think about what that meant etc..
goHitzter4932: I was just thinking that they shouldn't be necessary at all
pascale: I like having them there
goHitzter4932: code can figure it out.
goHitzter4932: or search both
goHitzter4932: we are going to an intermediate page anyway
J-Lo: yes - I think it would be good to lose the radio buttons - confuses people...
gwg: there was the discussion on the list about it - you'd have to do two queries in effect, one searching gps and one searching terms
eurie: yeah, i prefer not to have them as well and have an intermediate page that lists # of terms with hits and # of genes with hits
rama: if we decide to summarize search results on the next page (5 hits in Funtiocn, 5 gene_product names, 5 hits in Process etc) then we can get rid of it.
val: I like the radio buttons, but I'm not sure they are good for a novice user
gwg: personally I would prefer the option to use the radio buttons if I knew what I was looking for
kchris: maybe we can lose the radio buttons for the main entry page, and move this type of stuff to an advanced search
pascale: right. the problem I have with the intermediate page is that there is no way anymore to go directly to a page
eurie: agree with val
rama: we will have the exact match option though gwg agrees with Pascale
gwg: exact match doesn't do the same job, though, because often you know an element of a term name, but not the exact string
goHitzter4932: gene symbols are not very much like GO terms
kchris: I think one of the main things we need to do with this entry page is make it EASY for novice users, i.e. not too many options
goHitzter4932: (except stuff like SNARE complex)
J-Lo: Karen - I agree
kchris: We can always have a more advance search for more advanced users
rama: Karen, yes, I agree
pascale: so if you clicked on 'exact match', you would skip the intermediate page?
gwg: agree, Karen
rama: Pascale, we can decide on that
goHitzter4932: the intermediate page is for when people type in "kinase"
gwg: I think the radio buttons should be there, but not have one of the options selected (as it is at the moment)
gwg: otherwise it will be annoying for power users
rama: if an user typed in serine/threonine kinase, on the intermediate page we can state that there is one exact match and several wild card matches.
gwg: I'm getting annoyed just thinking about it!
val: perhaps the intermediat page is *only * required when the results are of both types?
goHitzter4932: they have to be check boxes then, by definition 1 box of radio set has to be selected.
goHitzter4932: val - yes, if your code can guess well enough
J-Lo: can't we have them both ticked by default?
gwg: ben - not necessarily. you just don't have them selected when the page loads
kchris: I think Mike C is pretty keen on getting these radio buttons off the main entry page
goHitzter4932: SGD does this decetnly - if you type a gene name that matches exactly you go right to the page, other wise it searches everything. First search is very fast
gwg: if the search was fast, it would be fine
rama: we have to test it out.
goHitzter4932: seth (since you will be writing this) - do you think it will be hard to distinguish types of queries? Does anyone track queries typed into amigo?
sjcarbon: on the server side?
gwg: possibly Mike?
rama: I can check with MikeC.
gwg: we'll have to find out
J-Lo: can we set this up on the toy server? or is that impossible?
rama: there are two camps- one for radio buttons/check boxes, one for complete removal of radion buttons.
sshu: web server access log should tell us type of queries.
rama: from the front page i meant.
sjcarbon: there is an issue with the kinds of queries and the logic in the system
gwg: let's do some prototypes and see what works best in terms of performance and user satisfaction
rama: Amelia, Yes, I was about to suggest that
goHitzter4932: I seem to recall that it uses posts instead of gets or something that makes it hard.
sjcarbon: no, but there is a fundamental difference in how thw two are handled
goHitzter4932: amelia, rama - I think you underestimate the amount of work it will take.
rama: sorry, i don't know what is involved. it was a suggestion.
gwg: I'm not saying do it immediately - I know there is a problem with the db structure
goHitzter4932: seth is hinting at it.
gwg: if it's something that we want to aim towards, though, it will have to be done at some point...
kchris: Maybe we should just do some mockups for look, of with and without buttons, and get input from the consortium as a whole which way we want to go, before we do any real work on the implementation side
gwg: I think it's more important to check we *can* do it on the db side first!
sjcarbon: this is very true
gwg: Seth / db people can explore this, and then if it looks like it's feasible, we can do some prototypes
rama: I think Karens point is: if the GOC wants it one way, then we can focus our efforts towards accomplishing that.
rama: sorry step back... Seth/Shu are going to check into having unchecked radio boxes?
sjcarbon: no radio bowes?
eurie: It's also the users. The users and member of GOC have different needs. WE need to be aware of that.
sjcarbon: check boxes instead?
goHitzter4932: the bottom line is that, some day, someone is going to have to rewrite the core amigo software.
sjcarbon: this is very true
gwg: let's find out if it's possible to do a query of gps and terms, and then worry about radio buttons or boxes or whatever
goHitzter4932: ok, I will be more explicit.
goHitzter4932: The kind of changes that the GOC/WC wants to implement are very, very difficult to do in the current system, which is already ready straining the limit on tolerable performance.
sshu: it is possible, query gps + query terms
goHitzter4932: let's say it's not only possible, but practical and efficient.
goHitzter4932: you still have the problem of counting annotations/displaying 100s-1000-s of annoations.
goHitzter4932: Why make incremental changes at this point?
sshu: if we want to do this, I think we need an intermediate page for summary, that way, we can search only skeleton infor so search is quicker.
rama: yeah, we then have to work on a useful intermediate page
J-Lo: so if we need to re-write AmiGO fairly soon, is there any point doing these changes we're working on now?!
goHitzter4932: you mean the mockups?
goHitzter4932: I don't think so.
sjcarbon: a rewrite will take time
sjcarbon: there is no reason to completely stop development
goHitzter4932: BUT I am not an expert on the software
gwg: the mock ups are ready to go now - they don't use any future software
sjcarbon: surface changes are relatively quick to make
goHitzter4932: it's really your call seth. Stanford has no programming resources to allocate to amigo beyond trying to speed up loading
sjcarbon: the mockups can be added almost immediately
rama: I want to summarize at this point
gwg: I think we should implement them for this release as they are an improvement on the old, if only because they're now W3C compliant html
goHitzter4932: OK, I have to go I have a meeting with Eurie. My final point was that Seth needs to decide what he can and cannot do in what time frame.
rama: regarding mock ups: we all like the new look, move the submit button to the side, see efficiency of data retrieval without the radio buttons
gwg: I have to go too, I have band practice
sjcarbon: ok--with a list of wants, i can ballpark them
rama: I know we haven't gone through the agenda completely. But we have made excellent progress. I suggest we close now and talk again on Aug15th?
rama: On Aug 15th, we willl start with the intermediate page
gwg: see you all then