Difference between revisions of "OBO-Edit Working Group Summary"

From GO Wiki
Jump to: navigation, search
(Group Leaders)
Line 39: Line 39:
*Jane Lomax (GO Ed., EBI)
*Jane Lomax (GO Ed., EBI)
*John Osborne
*John Osborne
*David Osumi-Sutherland (FlyBase)
*Victoria Petri (RGD)
*Victoria Petri (RGD)
*Erika Feltrin (TRAIT)
*Erika Feltrin (TRAIT)

Revision as of 06:22, 12 November 2008

3 July 2006


What is the group’s purpose?
This group guides the development of OBO-Edit to ensure usability and accessibility for a dynamic user group.
What makes this group necessary and unique?
OBO-Edit has become sufficiently complex, and sufficiently widely used, that we needed to move beyond the ad hoc development/testing approach that worked previously. This group ensures that OBO-Edit develops in directions that address the needs of its diverse and growing user community.
What is the lifespan?
This group will exist as long as OBO-Edit is undergoing active development. At present we assume that's equivalent to the lifespan of the GO project.

Group Leader

Midori Harris
Decisions are made by consensus among group members.


What are the key deliverables of this group?
  • Testing: We beta-test each version of OBO-Edit, and determine whether/when a version is ready for official release.
  • Assigning priorities for future OBO-Edit development tasks, such as new features. OBO-Edit is being used by many groups (e.g. GO, PO, PATO, NCBO) whose priorities must be taken into consideration.
  • User training: we are writing documentation, and plan to produce online tutorials and organize 'webinars' and live training workshops.
What criteria are used to set priorities?
John polled group members by email to establish priorities for the first round of feature addition. New feature requests are tracked at SourceForge. Criteria include how many people would use a feature, how much it would improve the speed or accuracy of their work, and how much it would help future development. Bug fixes always have high priority. Additional criteria may emerge.


  • Midori Harris (GO Ed., EBI)
  • Jennifer Deegan (GO Ed., EBI)
  • Nomi Harris (BBOP)
  • Amina Abdulla (BBOP)
  • Shuly Avraham (Gramene)
  • Rama Balakrishnan (SGD)
  • Carol Bastiani (WB)
  • Tanya Berardini (TAIR)
  • Karen Christie (SGD)
  • Alex Diehl (MGI)
  • Harold Drabkin (MGI)
  • Karen Eilbeck (SO)
  • Petra Fey (DDB)
  • Melissa Haendel (ZFIN)
  • Amelia Ireland (GO Ed., EBI)
  • Pankaj Jaiswal (Gramene)
  • Ranjana Kishore (WB)
  • Jane Lomax (GO Ed., EBI)
  • John Osborne
  • David Osumi-Sutherland (FlyBase)
  • Victoria Petri (RGD)
  • Erika Feltrin (TRAIT)
  • Chris Mungall (BBOP)
  • John Day-Richter (Former BBOP member and designer of OBO-Edit)

Aim is at least one representative from each MOD. One becomes a member by volunteering; we don't want the group to get too much bigger, but so far no one's been denied entry (and we'd hate to do that).

Meeting calendar

  • WebEx chats most weeks at 9:30am PDT
  • Longer 'webinar' sessions at a frequency to be determined (there's been one so far)
  • Lots of email in between meetings

Metrics of success

  • Most important metric: Stable releases of OBO-Edit
  • Other metrics: bugs fixed; features implemented; documentation produced


  • GO Editors - main users of OBO-Edit within GOC
  • Annotators - some do content development; others use OBO-Edit for searching GO
  • OBO ontology developers - i.e. OBO-Edit users, both within and outside GOC (some overlap with GO annotators)
  • Software development group (Berkeley)
  • Production database/software group (Stanford)


Decision-making is by consensus following discussion via email and IRC. All email is on the mailing list

Tools: Using WebEx (formerly IRC) & email; considering Flash for online tutorials; professional webinar hosting will help a lot with sharing experience among ourselves and training others.

OBO-Edit testing follows steps:

1. automated testing (John)
2. manual testing
   a. 'pre-testing' (one curator)
   b. test commonly used editing tasks (several curators)
   c. test all items in test suite (several curators)
   d. test new features (several curators)

If a version fails automated tests, or if bugs turn up in manual testing, John does bug fixes and the procedures starts again with the next version.

Note: automated and manual testing suites are being developed by the working group. We will soon make more specifics available, probably on a wiki page.