AmiGO working group summary (Archived)

From GO Wiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

NOTE: This group is now defunct. Please see the Web Presence Working Group instead.

Summary for the AmiGO working group (May 5, 2006)

About the Group

Current Status

What is the group's purpose?

This group's purpose is to guide the development of new features on AmiGO and improve the usability of its functionalities.

What makes this group necessary?

  1. AmiGO is the only web application that can allow users to view the ontology and all the gene associations from multiple species.
  2. As more genomes are getting sequenced and annotated, more groups are submitting GO annotations and viewing them on the AmiGO interface is getting complex.
  3. Another important issue is performance, i.e., if there are thousands of annotations from various species to a term, how long does it take to retrieve all the annotations.
  4. And finally, usability. How easy it is to understand the data presented and navigate on AmiGO?

This group will ensure that AmiGO develops in directions that addresses the issues mentioned above and meets the needs of the growing user community.

What is the lifespan?

This group will exist as long as AmiGO is alive, undergoes development and at the moment we assume we will exist as long as the GO project is alive.

Group Leaders

Rama Balakrishnan (SGD) and Shengqiang Shu (Berkeley) Decisions are made by consensus among group members.

Activities

What are the key deliverables of this group?

  1. We test all new features in a version of AmiGO and determine when a version is ready for release to the public
  2. Assessing priorities for future AmiGO development tasks, such as new features.
  3. User training: We are writing help documents and plan to do workshops to train users.

What criteria are used to set priorities?

Several users have posted comments on the AmiGO SF tracker. We have gone through these items and always our first priority is to make sure there are no bugs. We then prioritize new feature development/enhancements based on usefulness/impact (how much it will help an user) and how much it fits into our future goals. Additional criteria may emerge.

Members

  • Rama Balakrishnan (SGD)
  • Karen Christie (SGD)
  • Eurie Hong (SGD)
  • Jane Lomax (GO editorial office)
  • Amelia Ireland (GO editorial office)
  • Val Wood (GeneDB, Sanger)
  • Pascale Gaudet (dictyBase)
  • Ben Hitz (SGD)

Aims to have a good representation from the MODs. We don't want the group to get too large, but so far we haven't denied entry to anybody.

Meeting Calendar

  • Lots of email
  • Conference calls
  • exploring the IRC option which has been very successful with OBO-Edit working group

Metrics for success

  • Most important: User-friendly interface, accuracy
  • Other metrics: bug-free, reasonable retrieval time for queries, help documents, new features implemented

Linkage

AmiGO is used by a wide range of users.

  • GO consortium, GO annotators
  • Users who do micro-array expression analysis, genomics research
  • Plant Ontology Consortium (POC)
  • Software group at Berkeley
  • Production database/software group, Stanford

The GO mailing list and AmiGO SF tracker serve as good forums for these users to give us feedback, comments.

Process

Decision-making is by consensus following discussion via email and/or conference call. We are also looking into building a user testing group/focus group for testing purposes.

AmiGO testing cycle:

  1. 4 releases each year
    • features for each release will be prioritized and posted on the AmiGO working group mailing list
  2. Working group will test a development site hosted at Berkeley
    • report bugs via email
    • Berkeley will address bugs
    • testing is opened to the larger GOC group (still on Berkeley server)
    • when the version is bug free, code will be checked into CVS by Berkeley
  3. Stanford SysAdmin folks will take over
    • test new release on a development server at Stanford (only few people will test the development server)
    • move to production