We have lured in around 8 to 10 people to participate in development. We have graphics designers, UX specialists, concept designers and a few code developers. Nevertheless this project does not look like a normal open source project. In normal case, code developers are the majority if testers are not included. Of course one must keep in mind that Open Coral project is still rather young.
Our development team is now ready to form smaller teams to focus efforts and create focus-groups. Keep in mind that groups and teams are different things or concepts. In brief teams share goal and is normally more coherent and focused than a group. I have written a little more about groups and teams in previous post. Discussion about formally labeling teams has occurred a few times in our community meetings. In the last community meeting (meeting minutes) 21.12.2011 community gave me a task to create a suggestion about the teams. So, here they are – 3 teams. Before I discuss the teams, a few guidelines that apply to all.
Leaking borders – reaching out
Teams are not meant to be restrictive. Team members are allowed (or even pushed) to participate over team borders. Those borders should leak. Those leaks enable information transfer among members and teams. Belonging to a team helps individual to focus and ‘feel’ more coherent. In the image on the left, red dots are community members (in teams). By the way, don’t let the image fool you even if it looks like a ovulation side-product 
Because members jump around in different teams (which is good), the teams overlap naturally. Some of the members become ‘bigger red dots’, because they operate on multiple teams (they have the energy and time to do so). There are also green dots – they are possible users and team members. It is our responsibility to get more people involved. If you see someone lurking around the project, just pull (gently) the lurking person in, don’t let go. Real world example of this is when someone comes to our IRC channel to see what’s going on, it is everyone’s responsibility to be polite and have a little chat with the newcomer. We must be as extrovert as possible. Of course if you know that you lack some skills in chit-chat and end up insulting the newcomer, then just be quiet 
However, I doubt that any of us is like that.
Every team has lead – sooner or later
Every team needs to have some of who takes responsibility of tasks belonging to the team. Holding team leader role does not equal to doing all the work. Team leader is expected to be at community meetings and tell others what has been done, what kind of problems have been encountered. Of course every member of the community (or even anyone – even not member of community) can do that, but it is team lead’s responsibility to take care of communication. He or she should have ‘balls’ or ‘guts’ to raise issues at community mailing list and in community meetings. Team lead does not dictate what team does, team lead is more like a facilitator and handles disputes (if not possible at team level, issue should be raised in community meeting).
Teams
As I mentioned before, I would like to see three teams, all of which have naturally raised lead person.
1. Concept designers
Some might call this team as architects, but that sounds so boring and too formal. These people have ideas, they understand the connections between great theories (yes, some of us a scientists) and practice. In fact, members of this team create new theories as a hobby! They are the cutting edge thinkers of Open Source communities, development and communication. I don’t know should I reveal this but most of the Open Coral development is based on testing new theories These theories are not constructed without thorough research, that has some times lasted for years and required months of ‘living with the open source developers’. The latter is often referred as anthropological approach. Team lead could fall in the hands of OP or Tere.
Responsible for the following (not exclusive list) issues, which are a bit hard to identify:
- Follow latest research on topics related to project concepts and ideas.
- Find suitable theories (technical and sociological) to apply in project and evaluate usability.
- Develop data models.
- Develop theories behind the Open Coral development: process, end-product and community.
- All other tasks given by the community meeting.
2. UX Team
As the name suggests, this team does UX and UI level design decisions (with the community’s acceptance of course). They are gurus, they know how users wish to use our services. They might not be so talented in ruby or rails, but might posses unbelievable skills with GIMP, Photoshop, Inkscpape, 3D Max, CSS and Javascript. Not only do they know which button users want to push, they also know how to make that button irresistible. I have a strong feeling that no-one will object if Kari (aka Kp) would take the lead of this team. He’s the one behind initial UI sketches described in here.
Responsible for the following (not exclusive list) issues:
- UI design (all services, including support services)
- All graphical elements needed in project
- UX in all (all services, including support services)
- Monitors and develops usability of Open Coral and other services.
- Implements javascript UI code (as far as possible, Core Developers Team will support)
- All other tasks given by the community meeting.
3. Core Developers
Inside this team Aapo has taken responsibility of Diaspora* related issues and development. Therefore I would love to see Aapo wearing the ‘Team Core Developers’ cape. I have taken responsibility of support services such as BugZilla, wiki, IRC (bots) and Piwik (page view statistics etc). It is not my responsibility, but I tend to make a lot of architectural-alike writings in my blog. Those discussions might be used in implementation, or not. This team is about code and systems. If you are known to find solutions to different software and system related problems, this is your team. Your solutions don’t need to be pretty (but it does not hurt if they are), it’s enough if solutions work. We can polish those together. If your are ready to dig deep with Rails, Diaspora*, databases, ruby, haml and other languages – join this team. Let’s make our code both efficient and pretty. Oh, almost forgot: we use open source, we live open source life, we contribute back to community. Proprietary prone developers might feel a bit alone in this team.
Responsible for the following (not exclusive list) issues:
- Manages databases and servers
- Installs and manages all services in project servers (including Diaspora*, wiki, bugzilla, IRC bots and webpages).
- Implements features to core system.
- Implements features to UX/UI level in co-operation with UX Team.
- All other tasks given by the community meeting.
Issues not covered
In addition to that I will continue as community manager. I can’t say that I’m too experienced community manager, but I have managed MeeGo Network Finland (now that community is going to be put down), which at it’s peak contained around 200 members from several cities in Finland. My style is should I say – proactive. I like to think things forward and anticipate things as far as possible. Yet I do understand (because of my experiences) that things tend to go as they do, not according to plans. I have had hard opinion exchange with some members of communities that I have been (and still am) member of. I don’t give up easily, I want facts not opinions. When our community grows, we might need to set up a few more teams (like IT -team), but let’s not worry about that yet.
Join the discussion
Final note: this team model is not yet accepted by the community. This blog entry functions as opening for determining teams. Discussion about the subject continues in Open Coral mailing list, in our IRC channel (#open-coral at freenode) and in next community meeting (09.01.2011).
Content is available under 
2012, Jarkko Moilanen. CC BY-NC-SA 3.0
Related posts:
If you enjoyed this article, please consider sharing it!
