Feature development process

The feature development process needs to be defined in a way that's accessible to Brainstormers (=including anyone with an idea that deserves to be heard), developers and admins to have a say of what gets implemented. Parts of this process have been worked on already, but pulling it all together and having a sample project executed using the process would help people see how exactly things are getting worked on. The process is under discussion on the Brainstorm group.

(note: I'm mostly documenting what is partially existing already, since I realized we do have some of this figured out. I hope to bridge some of the remaining gaps soon in writing and practical issues. My credits go to: BONTOUR for starting up the Brainstorm group as a place for all those crazy ideas, Brainstormers, fellow developers Kasper, Joe and MATRIXPOINT for hard work on code and creating the essential pieces of this process Anu 05:57, 21 January 2007 (EST))

Idea to Feature process in CS

Eureka!

Idea comes in from

• Brainstorm group (major forum for user participation since quite a while)
• Contact us questions (need to implement a way to have developers more aware of this)
• Developers themselves
• Various CS Organizational groups with different levels of of privacy

People react to it in the groups

• Brainstorm

• Contact us questions: in case of any ambassadors overlapping Brainstormers, post it in the brainstorm and follow the Brainstorm process

• Developers
  • minor improvements (e.g. languages moved into different table to be able to make more advanced queries)
    • do it yourself!
  • issues that might have a possibility of stirring things up and pissing people off - ask the relevant stakeholders before releasing on the live site (release the feature in beta-testers group or other forum, depending on the situation). Preserving the right for developers to use their own judgement on minor, likely non-controversial issues, has proven to be more effective in getting things done than asking everyone for every little change made.

Other parts of this process aim at providing a way for anyone willing to participate to have veto-powers at various stages. Largely controversial issues should be dealt with with dignity and mutual respect between people participating in the process and the developers, but in order for progress to be made total agreement between everyone cannot be relied upon at all times.

• CS organizational groups with specific needs
  • e.g. ambassadors, security, translations...
  • go-to intermediate/developer for each group
  • current situation (might need more refining): core developers are tapped into everything, one way or another.

Incubation

(to be defined/refined)

• An organizational group on top of the Brainstorm group, that's specifically aimed at providing communications gateway for people interested in bringing forth and defining the ideas. Volunteers work on collecting feedback from the group on a wiki page. There are a few examples, but more help is needed here.
  • pros
  • cons
  • summary
  • links to threads in group(s)

• Intermediaries work through details to get into a workable solution, maybe using wiki pages to summarize and document their progress
• possibly polling the groups over to-go-or-not decisions involved in the process (is the idea supported by the community, or if there are smaller issues that need community voice)
• IF possible (and developers being able to work with it), tear the new feature apart into smaller chunks and post it into bug tracker.
• In case of a major new project idea, new group could be made just for this project

Gathering interested developers

In a volunteer organization, it is not always easy to get people working on stuff they were not directly involved in coming up with (ie. developers only want to work on ideas they thought of originally, or find interest in). This part of the process seems to be tricky - even with plenty of community support and some developer interest, many issues keep pushed back until the personal-interest stuff is dealt with.

Part of the problem is that there are very few developers actually working on the code, and getting new people involved and more importantly, KEEPING them involved and productive has proven to be difficult.

If YOU want to help with this, please contact Kasper (GUAKA) and be prepared to sign the NDA (non-disclosure agreement).

New Feature Playground

Before feature can be released on the live site, it should go through series of beta tests in the and in case there might be some controversy, feedback from people participating there should be heard and reacted to before releasing.

Software release

In case of major new feature, it could be posted on the main news spot on the front page (perhaps via the Community Voice group). Minor features getting implemented should be updated wherever they originated from, and in the bug tracker (in case they were posted there).

Miscellanous

Shortcut for minor things

Sometimes a developer has an idea to improve the site in a non-controversial way, or she gets an idea from a discussion (online or IRL) and implements it directly.

Participation

Couchsurfers being less driven by values of the corporate culture, defining a process that is effective in getting things done while providing enough freedom for the free-spirited people developing the site is tricky to say the least. Many times it's easier to talk about how things SHOULD get done instead of actually participating in the bulk of work that NEEDS to get done. This is why the core of this process is defined by participation: you create change by being part of it.