The CouchSurfing Wiki, an informal workspace which anyone can edit.

A few sample projects developers have been involved in during and between the Montreal & NZ collectives

Contents 1 People 2 John: Polls 3 John: Location fixing 4 John: New default couchsearch sorting algorithm 5 Joe: New layout 6 Kasper: this wiki 7 Anu: Ambassador structure coding 8 Conclusion

People

Note: there are other members in the tech team, and this is not a comprehensive summary of all projects completed since the Montreal collective. Vaporware not included ;)

• John
• Anu
• Joe
• Kasper
• Casey
• Chris
• Mattthew
• Promitheus

John: Polls

• Initiated in Montreal (assuming authorization by the admins present)
• Key participants (after John's initial efforts to build the first version of the software): interested people from the Cockroach group serving as usability and beta testers
• Problems
  • lack of technical support after John's departure from the collective due to insufficient communications by tech team leadership, blocking development as needed access to main CS software pipeline was missing. No other developer active at that time was aware of the project so could not provide John with more credentials at the same time other new developers were getting on board.
  • stalled due to lack of admin input even after repeated requests to have it, and multiple invitations to participate
  • change requests by the admins way too late into the development cycle, after going through series of iterations with the community already
• Result: Polls available in groups, subject to group moderator's approval (non-org groups)

John: Location fixing

• Initiated due to frustration with non-happening location fixing efforts (at least the time between Montreal & Nelson)

• Key participants: John for the software development, gathered volunteers for initial testing from groups and through the contact us section
  • after finalization of the software, more volunteers were drafted from ambassador's group to deal with fixing locations on a wider scale

• Problems
  • lack of action start this off
  • lack of communication as the project was going on, so updating our paid-for database overrode fixes by volunteers (twice!)

• Result: active location fixers group with effective and maintained tool; most locations fixed

John: New default couchsearch sorting algorithm

• It has been discussed time and again in the groups - taking action was only a matter of time
• Who: people participating into initial discussion in Brainstorm group, then collected into a specific project group
• Problems
  • Lack of availability of people able to modify the database for the needs of the application
  • No known communication problems :) this was a great example of community-initiated project that seems to have proceeded without major disapprovals and miscommunications, and finalized with good results, and with Casey's endorsement
• Result: new couchsearch sorting allowing less exposed members get hosting experience, and surfers finding available couches easier

Joe: New layout

• Initiated by need for simpler navigation for the site (as observed by the initiators)
• Who: Joe, Mattthew & people around at the CSC
• Problems
  • lack of "universal approval"
  • lack of receptivity to wider spectrum of opinions locally & outside the Collective house
• Result: can be chosen to be used in user preferences (profile -> edit -> theme: Latest look)

Kasper: this wiki

• Initiated by do-ocracy + wikimania ;) (and the need for travel guides on the site, which was part of the initial agenda as far as I know)
• Who: Kasper
• Problems
  • lack of approval by the admins
  • perceived lack of communication from both sides (admin & tech...)
  • concerns from the community: lack of integration with the rest of the site

• Result: an open dashboard for location guides and supporting documentation for CS functionalities

Anu: Ambassador structure coding

• Initiated months and months ago by the admins, catalyzed by Kasper's actions to enable people toggling ambassadors, Anu ended up doing the "levels" work since no-one else had stepped up by mid-january 2007.
• Who: Anu & Promitheus (emailing, IMing specs), a few current to-be-global ambassadors as beta-testers, ambassador's group for asking some occasional direction (for this-or-that smaller coding decisions)
• Problems:
  • lack of initial go-for-it attitude, hugely alleviated after Promitheus took the lead in defining & refining the project
• Result: the new ambassador structure

Conclusion

Past projects seem to work best when there's: (note: sub-bullets by Chris Burley)

• one project leader (as these were coding projects, a lead developer) accountable for progress (with lack of leadership, flexible self-starters have been proven to get things done)
  • We would benefit by creating "champions" and assigning them certain sections of the site or projects.

• enough authorization for the project earlier on (authorization = "go for it" support, and enough independence in making day-to-day development decisions regardless of admin input)
  • These ideas and projects will be highly directed by the following
    • Does it follow the mission?
    • Does it help the core site requirements of CS?
    • Do we have enough developer resources and developer interest to complete this project?
    • Does the community actually desire this feature? - know with polling, group feedback

• involvement based on interest rather than status - network of individuals rather than static dedicated teams allocated into "departments"

• community initiatives based on observed needs from the community rather than status-based initiation of the project ("admin vs surfer" -initiated projects)

• frequent & flexible communications (specialized groups, personal emails, instant messaging)

• new groups were created to handle communications specific for the project - open groups were mostly used, which seems to work reasonably well. Group ranters usually don't have the energy to contribute towards ACTUAL changes ;)

• In general, being aware of what's going on both within the tech team and overall in the organization helps to make the most informed choices in day-to-day development.

• Open and honest communication enables identifying possibilities for improvement whereas closed communication channels often cause the same mistakes being made over and over again.