<> = About this Document = This document summarizes the results of the RFC 2 discussion during the 2005 Cytoscape Retreat. * Section 1 documents the final group ideas. Ideas which garnered the most ideas are shown first. * Section 2 documents individual ideas from Cytoscape retreat attendees. = Section 1: Final Group Ideas = == Idea 1: Gather Feedback from Cytoscape Users == Total Number of Votes: 6 Summary: * Cytoscape has thousands of users. We should develop a feedback and information gathering mechanism for this large user base. * Feature prioritization should be based on user feedback. * Display statistics on the Cytoscape site about most liked, wanted, and disliked features. * Organize user meetings, perhaps in combination with another meeting users might attend. * Provide easy mechanism to make feature requests, submit new ideas. * Create a User FAQ * Create a User Q&A forum online for new users (Cytoscape discuss seems very programmer oriented) * Conduct user survey. == Idea 2: Create Development Coordinators == Total Number of Votes: 6 Summary: * Partition and assign rotating responsibility for development areas. * "Development coordinators" will be tasked with centralizing and facilitating communication between areas. * Posts held for 1-2 years. * May need one top-level coordinator to arbitrate development coordinators and cover misc. tasks. == Idea 3: Be Clear About Use-Cases and Long-Term Vision == Total Number of Votes: 4 Summary: * Implement a process for defining use-cases, and building community consensus. * Adopt a Mozilla-like process for development to reach these goals. * Implement this for 2.3; maybe not possible for long-term vision. == Idea 4: Adopt a more Systematic Development Process == Total Number of Votes: 3 Summary: * User requirements gathering (talk to our users more) * Technical specs and documentation * Coding * Testing * User Feedback * Documentation for the end-user == Idea 5: Create a new Project Coordinator / Architect == Total Number of Votes: 1 Summary: * Full-time position * Central contact for both developers and users. * Authority to make decisions, but answerable to core developers, PIs, and community. * Must know the code. == Idea 6: User-Driven Functionality == Total Number of Votes: 1 Summary: * Solicit feedback from biological users in outreach efforts (e.g. external demos, tutorials) in a systematic form, as follows: * ask a structured set of questions, including, "Why are you using the software?", "Can you perform this function now?", and so forth. * ask if users would be willing to weigh in again 6 months later. * Have a designated Cytostaffer whose role is to assess feedback and identify key functionality to address major concerns, and works closely with core developers to communicate and track targeted developments. * Track development efforts on the wiki, and open it up to users. = Section 2: Ideas from Individual Retreat Participants = == Nerius Landys == We seem to be easy swayed by problems reported by users, etc. This forces us to focus on short-term development goals rather than long-term goals. To see Cytoscape really break through, we should be focusing on what Cytoscape will become five years from now. == Chris Workman == Rotating officers for development areas (MVC might be a natural breakdown). "Development coordinators" help to centralize and facilitate flow of information. An office would also be need to coordinate the development coordinators. Posts held for 1-2 years. == Allan Kuchinsky == Collaborate with usability / UI research groups at universities. Do student usability review projects; use Cytoscape UI as a vehicle, e.g. for heuristic walk-throughs. == Mike Smoot == Create a project manager / chief architect. Must know the code; must have authority to decide what goes in / stays out and have veto power over PIs. Should be dedicated to Cytoscape work - not a part-time gig. == Michael Creech == Define a process for reviewing and determining Cytoscape core additions / modifications made by the community. == Janette Jones == Create a project administrator. Two functions to oversee: understand timings and linkages / codependencies of modules and also synthesize feedback from the user community (ie. keep track of who they are; organize scheduled feedback from them, and feed that back to the Cytoscape developers. == Patrick Warren == Open a structured route for user feedback, e.g. online polls for feature prioritization, online user feedback form, etc. == Gary Bader == Create a clear group-based process for biological use-case driven core feature prioritization and implementation review. Be clear about our use-cases (bio-focused); use this to prioritize new features; review by group of new core features; do this early in the release cycle. Right now, we are not clear about our use cases. == Scooter Morris == Adopt (and refine) a working open-source model. Mozilla defines 'module owners" who take directions / responsibility for sections of the code base. Developers submit their code for review, and depending on the module, super-review. Module owners can change over time, but provides a single point to collect ideas about module directions. == Alex Pico == Designate a project manager to oversee all development efforts and organize / visualize how it all fits together in the context of specific user cases. == Melissa Cline == Identify holes in existing functionality through outreach to external users. Solicit feedback in external demos, tutorials, etc. directed at biological users. Select 2-3 key holes to address in 2.3. Track efforts on key holes through the wiki; with participation from users. == Guy Warner == Develop Cytoscape to address the emerging needs of users. Improve usability. Ensure Cytoscape keeps pace with its users. Make the simple things even easier. == Benno Schwikowski == The lack of concrete persons taking charge of one or the other aspect of the project has been a growing weakness of the project. Without affecting the current levels of identification with the project, we could designate -- possibly by election -- people what take active charge and responsibility for a number of specific higher-level issues, e.g. software architecture, user interface, etc. == Willem Ligtenberg == Split project up in more layers. Core (kernel) = graph model plus renderer. Visualization = makes the core usable, but nothing more. Plugins = (Programs) allow you to do exactly what you want. == Benjamin Gross == Create a new rotating position for "Chief Architect". Nobody has an entire picture of the code base. Too much refactoring going on. == Keiichiro Ono == Start from documents, not from coding (UML, etc.) Since there is no comprehensive documentation for developers, it's hard to maintain other's code. == Iliana Avila == Be a lot more user oriented. == Amy Wiles == Improve user input as to what feature they would like to see / ability to get help on Cytoscape usage. Perhaps a simple FAQ or online Q&A that would not be emailed out to everyone to aid new users. Currently, mailing list seems very programmer oriented. == Andrew Kossenkov == You can't open files if they are not in the machine you're working on. Make it possible to get files from remote servers. == Adeleye Yeyejide == Improved interaction with user: Plugin development, feature requests, how new features are determined. Survey of users and what they require. Someone should be in charge of interacting with potential users. == Aditya Vailaya == Cytoscape has had 1,000s of downloads. We should be gathering feedback from this large user base. Have a feature prioritization / gathering via Cytoscape discuss / announce lists; collate statistics over the next month or so. Development of prioritized features. == Trey Ideker == More structured organization of core developers. Stricter cvs control; avoid sweeping core changes; appoint chief developer; build website clearing house; adopt procedures as a group. Improve task scheduling, coordination, responsibility, and timeliness.