← Revision 2 as of 2005-12-05 16:47:27
Size: 1039
Comment:
|
← Revision 3 as of 2005-12-05 16:57:47 →
Size: 3061
Comment:
|
Deletions are marked like this. | Additions are marked like this. |
Line 23: | Line 23: |
== 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 comunity 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 developerrs to communicate and track targeted developments. * Track development efforts on the wiki, and open it up to users. |
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 document 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 comunity 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 developerrs to communicate and track targeted developments.
- Track development efforts on the wiki, and open it up to users.