Differences between revisions 30 and 63 (spanning 33 versions)
← Revision 30 as of 2005-11-28 16:50:31 →
Size: 11492
Editor: mskresolve-b
Comment:
← Revision 63 as of 2005-12-05 20:39:52 →
Size: 6648
Editor: mskresolve-b
Comment:
Deletions are marked like this. Additions are marked like this.
Line 7: Line 7:
RFC 2 is divided in two parts: RFC 2 is divided in three parts:
Line 9: Line 9:
  * Part I consists of Ethan's interviews with six Cytoscapers (Trey, Gary, Ben, Allan, Aditya, and Rowan). I had hoped to interview more people before the Cytoscape retreat, but unfortunately didn't have time to get to everybody. In Part I, I have done my best to paraphrase people's comments, and I have not indicidated who said what.
  * Part II consists of ideas which were culled from Ethan's interviews, and are now presented as concrete proposals to the larger group. 		  * 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.
Line 16: Line 17:
== Part I: The Interviews == = Part I: The Interviews =
Line 18: Line 19:
=== Question 1: How do you feel about the quality of the 2.2 release? === ["/Part 1"]
Line 20: Line 21:
==== Cytoscaper #1: ==== = Part II: Results from 2005 Cytoscape Retreat =
Line 22: Line 23:
  * We pushed the release date out too much. We should have coordinated our efforts much earlier; we probably could have done something by August. We could have done a much better job if we had coordinated earlier on. I think this compromised the quality of the chosen feature set.
  * Next time, we need to decide the feature set straight away. Then, do design and implementation in the next 2-3 months, so that we can do a real six month release cycle.
  * Feature set was based on developer interests, not really based on user's feedback. We need a better mechanism to get more feedback from real users. 		["/Part 2"]
Line 26: Line 25:
==== Cytoscaper #2: ==== = Part III: Final Proposals =
Line 28: Line 27:
  * I think we chose the right set of features. For example, we chose a set of features that go well together, e.g. the new attribute browse goes well with the {{{CytoPanel}}} API. Plus, the editor fits in. Metanodes could have been in there too, and that would have been nice.
  * Timeliness could have been better. Quality could have been better.
  * That said, there are always trade-offs. In the tradeoff between: {{{GraphObjAttributes}}} v. {{{CytoscapeData}}} v. {{{CyAttributes}}}, I think we made the right decision. If we have had put Cytoscape 2.2 out the door a month ago without {{{CyAttributes}}}, it would have been a lot buggier. 		== Finalize Cytoscape 2.3 Objectives ==
Line 32: Line 29:
==== Cytoscaper #3: ==== During the last two hours of the Cytoscape Retreat, we devised a set of objectives for ["Cytoscape 2.3"]. We need to finish up this task and:
Line 34: Line 31:
  * I think we picked the right feature set.
  * Reasonable quality, but could be very much improved.
  * Smoothness of the user experience and user interace (GUI) is still a real issue.
  * Reviewed code is pretty high quality.
  * Release was slow, and could have been faster. We didn't work through all the dependencies between modules early enough. 		  * More clearly identify the use cases addressed.
  * Write the objectives in plain English. That way, Cytoscape users can more clearly understand what we are trying to accomplish. It's as if we write the release notes now, in anticipation of what we are actually going to build.
  * More clearly define the module owners.
 
== Invite User Feedback on Cytoscape 2.3 Objectives ==
Line 40: Line 37:
==== Cytoscaper #4: ==== Once we have Cytoscape 2.3 clear in our minds, and clearly written, we should email the cytoscape-discuss mailing list, and invite feedback from the larger community. Each proposed feature should have a comments page where the public can write in comments, and we should also provide a catch-all page where people can easily request new features.
Line 42: Line 39:
  * I thinks we focused on the right set of features. The most important thing is a stable API and being able to support plugin writers better.
  * Nonetheless, we dropped a few features that I wanted. This is probably because I didn't do a good enough job of communicating to others what I was working on.
  * Some groups doing core development are set on maintaining current functionality without soliciting feedback from other groups / users.
  * Quality of 2.2 is much higher than that of 2.1.
  * Need to better differentiate between core and not so core. If we had less stuff in the core, we could do updates of plugins more frequently, and updates to the core less frequently. 		A bit more background on this: many, many people would like us to solicit more feedback from our user community. Rather than just emailing out a generic email or creating an online poll, I think it would be much more effective if we went to our users with a specific plan, and asked them to comment on that plan. Users can then easily add comments to specific features, and the module owners will be responsible for trying to incorporate these comments into their RFC process.
Line 48: Line 41:
==== Cytoscaper #5: ==== == Adopt a Formal RFC Process for Each New Feature / Refactoring in Cytoscape 2.3 ==
Line 50: Line 43:
 * Right feature set.
 * Quality is middling.
 * Timeliness is poor.
 * I don't know why we always get caught up in core refactoring. We keep making such sweeping changes to the core API. This results in huge problems. As long as I can remember, we have always been doing this.
 * Core may not need to be refactored. We have a huge "not invented here" syndrome, which causes new developers to want to continuously refactor the core.
 * We should have a higher energy barrier to starting a new refactoring.
 * As contentious as this may be, perhaps we didn't need to refactor {{{GraphObjAttributes}}}. Instead of refactoring GOB, we could have been developing new stuff. And, we have a long laundry list of fixes that would have been more important to do.
 * I'm glad we have graph editor. Glad we have an attribute browser. Glad we have cytopanels. 		Each new feature / refactoring slated for Cytoscape 2.3 will go through a public review process via an RFC posted to the Cytoscape Wiki.
Line 59: Line 45:
=== Question 2: If you had to identify the biggest strength in the current Cytoscape development process, what would it be? === ["RFC_1"] will serve as a starting template for all RFCs.
Line 61: Line 47:
==== Cytoscaper #1: ==== Depending on the feature, the RFC should include the following:
Line 63: Line 49:
 * Distributed nature of development is a great strength. Core development is distributed; plugin development is distributed. Nothing is centralized at one place.   * Use case addressed.
  * Proposed user interface.
  * Proposed API.
Line 65: Line 53:
==== Cytoscaper #2: ==== 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.
Line 67: Line 55:
  * We have a supportive, smart group of people. As a new person coming in, I haven't been afraid to ask stupid questions. No real personal animosity within the group. No snide comments re: code.
  * Esprit de corps among the group. Talented group of people. 		'''Add a comment about this idea: ["/RFC_Comment"]'''
----
Line 70: Line 58:
==== Cytoscaper #3: ==== == Clarify Roles at the Beginning of Release Work ==
Line 72: Line 60:
  * Everybody is generally on the same page in terms of what needs to get done.
  * People work in an agreeable way. People are open to ideas. 		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:
Line 75: Line 62:
==== Cytoscaper #4: ====   * 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.
Line 77: Line 71:
  * Good backend support for graphs. We are now stabilizing the core APIs / data core structures.   * 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.
Line 79: Line 73:
==== Cytoscaper #5: ==== '''Add a comment about this idea: ["/Roles_Comment"]'''
----
Line 81: Line 76:
  * Small enough group that we know each other; comfortable working together.
  * Easy to get a hold of people. 		== Focus on Cytoscape 2.3 Objectives via Wiki and Weekly Conference Calls ==
Line 84: Line 78:
==== Cytoscaper #6: ====
  * People get along; people are willing to help out.
  * The group seems to have a strong belief in Cytoscape. 		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:
Line 88: Line 80:
=== Question 3: If you had to identify the biggest weakness with the current Cytoscape development process, what would it be? ===   * Make sure that the ["Cytoscape 2.3"] page is always up to date, and reflects current reality. This includes:
     * List of all proposed features / proposed refactoring
     * List of all module owners
     * Proposed Release Date
     * Status of individual modules
     * Who's doing what, e.g. who is the release manager, etc.
  * 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.
Line 90: Line 88:
==== Cytoscaper #1: ==== Ethan volunteers to lead up this item.
Line 92: Line 90:
  * We need to be more closely tied to the user community. '''Add a comment about this idea: ["/Focus_Comment"]'''
----
Line 94: Line 93:
==== Cytoscaper #2: ==== == Create Module Owners for each New Feature / Refactoring in Cytoscape 2.3 ==
Line 96: Line 95:
  * We have no central control. There is "no there there". Anybody can change things, take things out, put things back.
  * Lack of coordination. However, a strong centralized control would make things a lot less flexible.
  * In the spectrum of control v. anarchy, we probably ought to move a bit more towards control.
  * No project management. 		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.
Line 101: Line 97:
==== Cytoscaper #3: ==== For example, in Cytoscape 2.3, we might have the following module owners:
Line 103: Line 99:
  * We need identifying and prioritize depedencies early on.
  * We are not strict with ourselves in deciding what needs to be done first, and actually doing it first. We go more for what we are interested in.
  * For example, {{{CyAttributes}}} should have been done first. Could have saved a month if that was done first. 		  * Graph Rendering (Nerius)
  * Meta Nodes (Iliana)
  * etc.
Line 107: Line 103:
==== Cytoscaper #4: ==== Module owners might rotate or change at every release.
Line 109: Line 105:
  * We have multiple communication gaps: communication gap between what each group wants to see done v. what programmers want done v. what users want done; communication gap between PIs and programmers. '''Add a comment about this idea: ["/Module_Owners_Comment"]'''
----
Line 111: Line 108:
==== Cytoscaper #5: ==== == Focus on Usability of Visual Styles / Filters ==
Line 113: Line 110:
  * We don't coordinate well enough. We need to know who's working on what, and who's available. Part of that goes back to funding. We should make core work more consistent throughout all the groups. At the Cytoscape Retreat, many individuals expressed interest in "improving the usability of Cytoscape." However, this is such a large task, that we might not get very far. To narrow things down, Cytoscape 2.3 should focus on:
Line 115: Line 112:
==== Cytoscaper #6: ====   * Improving the overall usability of Visual Styles.
  * Improving the overall usability of Filters.
Line 117: Line 115:
  * There is not much holding the project together; not much accountability; sometimes little follow-up on important issues. Both of these items were triaged at the Cytoscape retreat as being very important features.
Line 119: Line 117:
=== Question #4: How does the Cytoscape software process compare to other software projects you have worked on in the past? === To Allan K's suggestion, we should reach out to and collaborate with usability / UI research groups at universities.
Line 121: Line 119:
==== Cytoscaper #1: ==== If we are able to substantially improve the usability of the visual styles / filters in Cytoscape 2.3, we can use this as a basis to improve the usability of other features within Cytoscape.
Line 123: Line 121:
  * Not really comarable to other projects.

==== Cytoscaper #2: ====

  * Compared to other projects, e.g. collaborative software across companies or standards work, Cytoscape is more chaotic. More fun.
  * Cytoscape is pretty productive as an open source community. Imagine how screwed up everybody else is!
  * Need to have a good way to gauge ourselves, e.g. one year after last year's retreat, let's look back at the last year, and do a real post-mortem.

==== Cytoscaper #3: ====

  * Better than other open source projects that I have been involved in.
  * People work very well together. No culture / personality clashes. People are generally easy going. There is a lot of dialog.

==== Cytoscaper #4: ====

  * The strangest about Cytoscape is that we will be busy developing something; then we make abrubt changes w/o clear direction.
  * We don't have someone in charge at the code base level. We have PIs, but they are not close enough to the code. We need a manager of some type who can manage at the code level on a day-to-day basis.

=== Question #5: If you were god, and could change one thing about how we develop Cytoscape, what would it be? ===

==== Cytoscaper #1: ====

  * Get closer to the user community.
  * Improve our development tasks, such that they are done on time.
  * Get a project manager. Mark was playing that role before he left. But, we really need someone to synchonize work.
  * Right now, no one is taking charge, and that's why we has slipped.
  * No need to be in panic mode right now. We could have avoided this with better coordination.

==== Cytoscaper #2: ====
   
  * Give everybody a lot of travel money. Have more face to face contact within the group. 3-4 retreats / year. Informal code get-togethers. More face to face interaction.
  * Create an exchange program, e.g. Nerius goes to NY for a week, etc.

==== Cytoscaper #3: ====

  * Devote one person in the group to Chief Architect. Fulltime role. This person would: coordinate everyone else; maintain integrity of the code; perform code reviews, etc. Not a project manager.
  * Chief Architect would learn / study the complete code base. Understand the big picture view of the code base; advise or prioritize refactoring issues; organize / run all unit tests, etc.

==== Cytoscaper #4: ====

  * Put way less stuff in the core, and move many core features into plugins.

==== Cytoscaper #5: ====

  * More organization; less core refactoring.
  * Create a specific position devoted to user interface issues.

==== Cytoscaper #6: ====

  * Get more involvement of all groups in core development.
  * Create rotating positions for important roles, e.g. Chief Architect, Release Engineer, etc. This would help sprend knowledge throughout the group.

=== Question #6: What else would you change? ===

==== Cytoscaper #1: ====

  * Developer a better way of gathering requirements.
  * RFC process for {{{CyAttributes}}} was good. We should do more of that.
  * Wiki has been a really important tool. We should use it more.
  * We should make sure that all design and API changes are posted to the Wiki for public review.

==== Cytoscaper #2: ====

  * Without the money for travel, maybe we could have pairwise programming on some shared components. Perhaps via Web Ex.
  * Perhaps we should consider hiring a project manager.
  * Perhaps a code czar, or a "software librarian". This person would be in charge of bightly builds, test scripts, etc.
  * Having a QA team would also help.
  * Recruit usability people. Perhaps we could hook up with usability people within universities.

==== Cytoscaper #3: ====

  * Create a visual road map of where Cytoscape is going.
  * Make increased use of the Wiki.

==== Cytoscaper #4: ====
   
  * We should have clearer definitions of who is doing what.
  * I usually don't know what half the group is working on.
  * Get more feedback from plugin writers.

==== Cytoscaper #5: ====

  * Every release should be focused on a common set of features, or 1-2 well-defined use cases.
  * Very few people are both developing and using Cytoscape on a daily basis. Need to get more of those people.

== Part II: The Recommendations ==

Under Construction 		'''Add a comment about this idea: ["/Usability_Comment"]'''
----

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

Finalize Cytoscape 2.3 Objectives

During the last two hours of the Cytoscape Retreat, we devised a set of objectives for ["Cytoscape 2.3"]. We need to finish up this task and:

  • More clearly identify the use cases addressed.
  • Write the objectives in plain English. That way, Cytoscape users can more clearly understand what we are trying to accomplish. It's as if we write the release notes now, in anticipation of what we are actually going to build.
  • More clearly define the module owners.

Invite User Feedback on Cytoscape 2.3 Objectives

Once we have Cytoscape 2.3 clear in our minds, and clearly written, we should email the cytoscape-discuss mailing list, and invite feedback from the larger community. Each proposed feature should have a comments page where the public can write in comments, and we should also provide a catch-all page where people can easily request new features.

A bit more background on this: many, many people would like us to solicit more feedback from our user community. Rather than just emailing out a generic email or creating an online poll, I think it would be much more effective if we went to our users with a specific plan, and asked them to comment on that plan. Users can then easily add comments to specific features, and the module owners will be responsible for trying to incorporate these comments into their RFC process.

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"]

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"]

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. This includes:
    • List of all proposed features / proposed refactoring
    • List of all module owners
    • Proposed Release Date
    • Status of individual modules
    • Who's doing what, e.g. who is the release manager, etc.
  • 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.

Ethan volunteers to lead up this item.

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

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.

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

Focus on Usability of Visual Styles / Filters

At the Cytoscape Retreat, many individuals expressed interest in "improving the usability of Cytoscape." However, this is such a large task, that we might not get very far. To narrow things down, Cytoscape 2.3 should focus on:

  • Improving the overall usability of Visual Styles.
  • Improving the overall usability of Filters.

Both of these items were triaged at the Cytoscape retreat as being very important features.

To Allan K's suggestion, we should reach out to and collaborate with usability / UI research groups at universities.

If we are able to substantially improve the usability of the visual styles / filters in Cytoscape 2.3, we can use this as a basis to improve the usability of other features within Cytoscape.

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

RFC_2 (last edited 2009-02-12 01:04:11 by localhost)

Funding for Cytoscape is provided by a federal grant from the U.S. National Institute of General Medical Sciences (NIGMS) of the Na tional Institutes of Health (NIH) under award number GM070743-01. Corporate funding is provided through a contract from Unilever PLC.

MoinMoin Appliance - Powered by TurnKey Linux