RFC_2/Part_1

Clear message

About this Document

I had hoped to interview more people before the Cytoscape retreat, but unfortunately didn't have time to get to everybody. Below, I have done my best to paraphrase people's comments, and I have not indicated who said what. The order of comments, e.g. Cytoscaper #1, #2, etc. is arbitrary.

Question 1: How do you feel about the quality of the 2.2 release?

Cytoscaper #1:

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

Cytoscaper #2:

• 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 browser 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.

Cytoscaper #3:

• I think we picked the right feature set.
• Reasonable quality, but could be very much improved.
• Smoothness of the user experience and user interface (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.

Cytoscaper #4:

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

Cytoscaper #5:

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

Question 2: If you had to identify the biggest strength in the current Cytoscape development process, what would it be?

Cytoscaper #1:

• Distributed nature of development is a great strength. Core development is distributed; plugin development is distributed. Nothing is centralized at one place.

Cytoscaper #2:

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

Cytoscaper #3:

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

Cytoscaper #4:

• Good backend support for graphs. We are now stabilizing the core APIs / data core structures.

Cytoscaper #5:

• Small enough group that we know each other; comfortable working together.
• Easy to get a hold of people.

Cytoscaper #6:

• People get along; people are willing to help out.
• The group seems to have a strong belief in Cytoscape.

Question 3: If you had to identify the biggest weakness with the current Cytoscape development process, what would it be?

Cytoscaper #1:

• We need to be more closely tied to the user community.

Cytoscaper #2:

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

Cytoscaper #3:

• We need to identify and prioritize dependencies 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.

Cytoscaper #4:

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

Cytoscaper #5:

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

Cytoscaper #6:

• There is not much holding the project together; not much accountability; sometimes little follow-up on important issues.

Question #4: How does the Cytoscape software process compare to other software projects you have worked on in the past?

Cytoscaper #1:

• Not really comparable 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 thing about Cytoscape is that we will be busy developing something; then we make abrupt 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 synchronize work.
• Right now, no one is taking charge, and that's why we have 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 spend knowledge throughout the group.

Question #6: What else would you change?

Cytoscaper #1:

• Develop 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 nightly 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.

MoinMoin Appliance - Powered by TurnKey Linux