AmiGO-chat-01Aug06

From GO Wiki
Revision as of 03:32, 3 August 2006 by Girlwithglasses (talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

rama: Hi All, Welcome to our first IRC Chat

eurie: hey

kchris: hi

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

pascale: hello

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: http://www.godatabase.org/cgi-bin/amigo/go.cgi?session_id=3727b1154023228&view=details&query=GO:0031500&search_constraint=terms&term_context=sibling

goHitzter4929: productin

goHitzter4929: http://www.godatabase.org/cgi-bin/amigo/go.cgi?session_id=3727b1154023228&view=details&query=GO:0031500&search_constraint=terms&term_context=sibling

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?

goHitzter4929: no

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?

pascale: sure

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?

pascale: sure

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

J-Lo: no

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

goHitzter4932: fine

kchris: fine for me

sjcarbon: ok

eurie: fine, as long as we can try keep it to an hour or so

J-Lo: fine

rama: Okay, we will do IRC and switch to phone if we have a need to hear eachother's voice

pascale: ok

rama: item-2.3

rama: WIKI

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

pascale: ok

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

pascale: page

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

pascale: ok

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'?

gwg: uh-huh

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

pascale: http://wiki.geneontology.org/index.php/Talk:AmiGO_mock_ups

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?

rama: yes.

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

sjcarbon: true

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...

J-Lo: yep

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

pascale: ok

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

pascale: right

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?

val: wou;d

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

J-Lo: okay

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

J-Lo: yep

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.

goHitzter4932: g00t

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?

gwg: yup

rama: The front page- GOOGle like look?

gwg: yup

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"

pascale: ok

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: anyone?

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?

sjcarbon: ok

rama: On Aug 15th, we willl start with the intermediate page

gwg: see you all then


Back to AmiGO meetings and conference calls