OBO-Edit Working Group Summary

From GO Wiki
Revision as of 06:57, 8 April 2014 by Gail (talk | contribs)

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

3 July 2006

Purpose

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.

Subscribe

Subscribe to the working group mailing list on Sourceforge

https://sourceforge.net/mailarchive/forum.php?forum_name=geneontology-oboedit-working-group

OBO-Edit Working Group Meeting Calendar

View the OBO-Edit calendar


Activities

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?

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.

Members

  • Nomi Harris (BBOP)
  • Chris Mungall (BBOP)
  • Midori Harris (PomBase)
  • Rebecca Foulger (GO Ed., EBI)
  • Shuly Avraham (Gramene)
  • Rama Balakrishnan (SGD)
  • Karen Christie (SGD)
  • Alex Diehl (Cell Ontology; U Buffalo)
  • 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)
  • Ramona Walls (New York Botanical Garden)
  • Laurel Cooper (Oregon State; POC)
  • Terry Meehan (MGI)

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 chat/screen sharing interface for demos in conjunction with conference call on the 1st and 3rd Tuesdays of the month at 8:30am PST/PDT
  • Email in between meetings

Metrics of success

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

Linkages

  • 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)

Process

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

Tools: Using WebEx. Conference calls & email; professional webinar hosting will help a lot with sharing experience among ourselves and training others.

OBO-Edit testing follows steps:

1. automated testing
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, Amina 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.