Community_development_process

Cytoscape is an open-source project that aims to develop a network visualization and analysis application and extensible platform. Originally developed at the Institute for Systems Biology, Cytoscape has grown to involve many groups. Currently, the groups collaborate efficiently via the following process.

Communication

• General communication

  • Cytoscape.org website

  • Cytoscape wiki

  • Cytoscape announce mailing list

  • Cytoscape discuss mailing list

  • Cytoscape CVS commit message mailing list

• Internal communication (open to core Cytoscape developers)
  • Weekly conference call
  • Internal development mailing list

Process

The Cytoscape development process philosophy supports effective collaborative tool building. The groups involved in Cytoscape development have all recognized common needs in network visualization and analysis as well as individual needs and priorities. Ideally, working together saves large amounts of time for each group and allows each group to spend time working on more important projects, like life science research. To effectively manage this process, the groups collaboratively brainstorm about common needs at an annual Cytoscape Retreat and throughout the year over conference calls and on mailing lists. All features that are discussed are tracked.

There are two general types of features

• Plugins (Non-core): available as external plugins that are optionally packaged with Cytoscape
• Core: Ideally, Cytoscape core remains a lean and modular framework for maximal reuse. To acheive this, core features are shipped as part of Cytoscape either as:
  • Core code: present in the /cytoscape/src directory (application specific features, like menu additions)
  • Core library: jar file in the /lib directory) (majority of core features, like the graph library or task API)
  • Core plugin: jar file always shipped with Cytoscape in the /plugins directory (majority of modular features, like filters, right-click menu, data format support, etc.)

Plugins

Plugins, or non-core features, are implemented as any plugin written by any interested developer anywhere. Developers implementing Cytoscape plugins are encouraged to make them available under an open-source license, but are free to make them available under any license, including a commercial one. Plugins that are publicly released can be announced on the Cytoscape announce mailing list and posted to the Cytoscape plugins web page by sending a message to the Cytoscape discuss mailing list.

Core features

A key aspect of development is that core task prioritization is based on the selfish needs of the groups involved. This ensures that features are implemented as quickly as possible and to completion. If a development group identifies a feature that they need for their research or other work and they are prepared to implement the feature, they communicate with the rest of the Cytoscape developers to make sure no one else is already working on the feature. If someone else is working on the feature, the groups collaborate to work on the feature. The features are implemented as plugins, where possible, in space set up for each user and group. When a group is ready with a feature, it is presented to the rest of the collaborators for review (API, features, code, etc.), at which point other interested groups provide feedback. Once feedback is incorporated and testing is complete, the feature is finished and packaged appropriately in the core. It is expected that core features are professionally implemented and include full Java documentation, user manual documentation and unit tests.

Modifying the Cytoscape core

As of February 2010, a more formal process for review and approval of changes to the Cytoscape core is being implemented. As Cytoscape grows, a defined process is necessary to both encourage contributions from the development community and ensure the high quality of Cytoscape code.

Overview: A team of facilitators ensures the process of consensus building and code review around core change proposals runs smoothly. An architect defines the design vision of the code.

Approval of core enhancement (consensus building process)

• Enhancement proposals are documented in bug tracker and wiki and assigned a primary facilitator. Facilitator maintains proposal status, which moves from incomplete -> open discussion -> design approval -> implementation -> code review -> implementation approval. Status is closed if proposal finishes or fails.

• It is incumbent on the proposer to engage the development community in discussion with the goal of building consensus and moving the proposal from start to finish. Facilitators will help move the process along.
• If consensus cannot be achieved at design or implementation approval steps during this process due to a disagreement, the proposal may be referred to the facilitator group for a decision.
• If the facilitator group cannot come to a decision, the proposal may be referred to the board of directors (code review sub-committee) for a decision.
• Anyone involved in a code dispute is excluded from deliberations.

Code review of new enhancement implementation and non-trivial bug fixes (code quality assurance process)

• Enhancements and non-trivial bug fixes must be reviewed and approved by any core developer outside of the work group of the implementer
• “Non-trivial” bug fixes are defined by the facilitators. Criteria are:
  • Number of lines of code
  • Number of classes affected
  • Impact on other code

Facilitators of process and code review (code quality assurance)

• Five core developers who are among the most knowledgeable about the Cytoscape code, one of whom is the architect. Facilitators will elect one facilitator as a chair to help organize the group.
• Annual nomination of facilitators and architect followed by a vote by core developers and board of director members maintains this group (each participant votes for as many nominees as they want and the five nominees with the most votes in each category are chosen). The board ratifies the vote results. Annual vote happens around July.1
• Facilitators are tasked to:
  1. Maintain proposal process (consensus building)
     • Facilitate the proposal consensus building process and encourage the ongoing development and growth of the Cytoscape developer community
     • Ensure that the weekly calls happen, are chaired and notes are taken
     • Mentor, review and make recommendations on enhancement proposals
     • Ensure enhancement proposals are properly tracked in wiki and bug tracker
     • Be responsive e.g. respond within 1 week
  2. Maintain code review (code quality assurance)
     • Maintain code review process by reviewing code or recruiting code reviewers from among all core developers and the external Cytoscape community
     • Decide whether a bug fix requires formal code review
     • Makes decision to approve proposals where there is disagreement or refers decision to the board of directors
  3. Represent the progress of the core development team to the board of directors

Cytoscape team roles

Core developer

• Develop core code
• Be knowledgeable about the core code

Architect

• A single core developer as visionary/designer of the Cytoscape core code

Facilitator

• A core developer voted to help maintain the core enhancement and code review process

Board of directors member

• PI/Manager at a core developer institution

Community member

• Any interested person in the Cytoscape community e.g. a plugin developer