TableOfContents([2])

About this Document

This is an official Request for Comment (RFC) for "improving the quality of the Cytoscape 2.3 release."

RFC 2 is divided in three parts:

• Part I consists of Ethan's interviews with six Cytoscapers (Trey, Gary, Ben, Allan, Aditya, and Rowan).
• Part II consists of ideas generated at the 2005 Cytoscape retreat.
• Part III consists of final, concreate ideas, which are being proposed to the Cytoscape group.

Status

This document is under construction.

Part I: The Interviews

["/Part 1"]

Part II: Results from 2005 Cytoscape Retreat

["/Part 2"]

Part III: Final Proposals

1. Adopt a Formal RFC Process for Each New Feature / Refactoring in Cytoscape 2.3

Each new feature / refactoring slated for Cytoscape 2.3 will go through a public review process via an RFC posted to the Cytoscape Wiki.

["RFC_1"] will serve as a starting template for all RFCs.

Depending on the feature, the RFC should include the following:

• Use case addressed.
• Proposed user interface.
• Proposed API.

Once posted to the wiki, the RFC owner should announce it via the cytostaff emailing list, and provide a specific deadline for public discussion. RFCs should be open for public comment for at least one week, and should provide a clear mechanism for adding comments.

Add a comment about this idea: ["/RFC_Comment"]

2. Clarify Roles at the Beginning of Release Work

Rather than wait until the end of a release to determine who is doing what, appoint people right now to key positions. Ideally, we should rotate these roles at each release in order to spread knowledge throughout the group. Here are the most important roles:

• Release manager: the release manager is responsible for coordinating work during the final 2-4 weeks of a release cycle. Responsibilities include:
  • Performing builds every few days and making the build available to testers.
  • Tagging the release in CVS
  • Generating javadocs
  • Updating the Ant Build file, as needed.
  • Coordinating the work needed for the Mac OS X release, and the Install Anywhere installation.
• Web Master: the web master is responsible for coordinating change to the Cytoscape web site, and deploying the final release to cytoscape.org.
• Documentation manager: the documentation manager is responsible for coordinating all efforts related to ensuring that the Cytoscape manual, Java help pages, and on-line tutorials are up-to-date.

Add a comment about this idea: ["/Roles_Comment"]

3. Focus on Cytoscape 2.3 Objectives via Wiki and Weekly Conference Calls

At the 2005 Cytoscape Retreat, we came up with a list of goals for ["Cytoscape 2.3"]. We need to maintain focus on these goals, and can do so in two ways:

• Make sure that the ["Cytoscape 2.3"] page is always up to date, and reflects current reality. [Ethan volunteers to take care of this.]
• Start out each weekly Cytoscape conference call with a concise review of the ["Cytoscape 2.3"] page, and get updates from each feature owner. The weekly conference calls tends to wander over many topics, and this provides us with a simple mechanism to refocus on shared priorities.

Add a comment about this idea: ["/Focus_Comment"]

4. Create Module Owners for each New Feature / Refactoring in Cytoscape 2.3

Each new feature / proposed refactoring in Cytoscape 2.3 should have one clear module owner, and this module owner must be specified on the ["Cytoscape 2.3"] page. The module owner is responsible for coordinating the RFC process for their proposed module, reviewing any code which affects the proposed module, and serving as a central point of contact for the module.

For example, in Cytoscape 2.3, we might have the following module owners:

• Graph Rendering (Nerius)
• Meta Nodes (Iliana)
• etc.

Module owners might rotate or change at every release.