Learning to Play Nicely With Others: TOS Chapter 3 and SD Chapter 2

The readings for this post are from the two texts we're using, and deal with working in a global community and working with a a project team, respectively.


TOS Chapter 3
This chapter is about learning how to interact with the open source global community.  No matter how big or small the project may be that you pick, you have to first and foremost understand that working on open source projects means working out in the open, and communication with everyone involved is the key element to doing so.  You have to remember that every FOSS community has their own way of doing things, their own culture.  This isn't influenced by the culture of the countries of those involved, but by the "shared experiences, humor, social norms, and conventions that define that community, building up a synthetic third culture".  The qualities of the community are listed as follows:

• Focus: What the community wants to achieve.
• Maturity and History: The age of the project.
• Type of Openness: This can vary from active communities with strict management hierarchy headed up by a development leader (read: dictator) to communities that are completely open to any and all.
• Commercial Ties: Whether or not the project is being sponsored by a company or companies.
• Subgroups: Whether or not the community operates as a whole or is divided into subgroups.
• Skills: Each community focuses on and requires a certain skill set for contributors, so having new contributors come it with skill sets not already a part of the project can be beneficial.
• Mentoring and Training: There's no Mr. Miyagi here, but some communities do have some simple training or mentoring programs to help the community grow and learn.  Wax on, wax off...

There are three main challenges that arise from working in a global community:
1.  Language barrier--this one is obvious.  I mean, sometimes understanding what another person is saying can be difficult from region to region in the same country, not just from country to country.  Establishing a common language (or, depending on the project, a common measuring system) is essential to breaking down the communication barrier.  Coding comes easily. Talking is hard.
2.  Time and distance--also obvious.  Not everyone operates on the same schedule; some prefer coding at night and others during the day.  Meeting face to face can be difficult because the other person could be halfway around the world.  Communicating through other methods, like via email and IRC channels, is a good way to overcome that.  Wikis and blogs are also a good way of communicating with others about your project.
3.  Ego--while there's not a lot of money (or none at all) involved when taking part in a FOSS project, wanting individual recognition can really hurt a community like this.  Acting like this will make others not want to work with you.  It's the same reason no one wants to pick you for their team in kickball--no one likes an egotistical jerk.


Exercise 3.5: Project Wikis
1.  Our project, XBMC, uses the MediaWiki software package for its wiki page.
2.  The project's history is in the wiki under Team XBMC-->XBMC.
3.  The last revision of the wiki was made on March 10th by Ned Scott.  I would consider this to be thriving since it's a very active project.
Exercise 3.7: Linking Your Blog to Planets
For this exercise we are to link our blog to our class planet (the class wiki).  We did this at the very beginning of the semester.
Exercise 3.9: Learning IRC
Already did this one at the beginning of the semester, too. Hooray!!
Exercise 3.11: Joining the Mailing List
XBMC doesn't have a mailing list, only a forum and bug tracker which I have joined.


That's it for TOS Chapter 3.  On to the next part of this post!!


SD Chapter 2
This chapter talks about interacting with a team and how to choose a good FOSS/HFOSS project.  Working in a team setting is like a development community, only it's on a much smaller scale and more structure.  Each team member has a key role, however, the same person may have two or more roles simultaneously.  They are:

• Team Leader: the person who oversees the development process.  Tasks include setting weekly agendas and milestones, assigning tasks to team members, coordinating overall system architecture, teaching other team members about new techniques, leading regular team discussions, and helping resolve design issues.
• Analyst: someone who understands the user's domain, elicits requirements, defines use cases, evaluates risks and alternatives, and sketches the initial design of the software to be developed.  Tasks may also include cost estimation and project scheduling.
• Developer: the person who writes test cases from requirements, and reads, writes, tests, debugs, and refactors program code.  Also refine requirements and use cases, write documentation and online help pages, and solicit feedback from users at each stage in the project.  Basically a programmer who can also read, write, and communicate effectively with users.
• User: the person who is knowledgeable about the application's domain.  Tasks are to review use cases, provide data for test cases, review the output of code written by developers, provide feedback on the quality of that output, and find bugs in the software after each iteration has been deployed.
• IT Technician: filled by persons who configure and maintain the technical environment used by the team.  Tasks are to set up and maintain the code repository, the staging server, the videoconferencing system, the team discussion site, and other software tools needed by the team to develop the software effectively.
• Observer: someone who is interested in watching the project develop and/or whose project management expertise may provide occasional high-level advice on particular design decisions.  This is a fairly passive role.

Team members must be respectful of one another (think the Golden Rule) because a collaborative effort isn't going to work if team members are acting like complete jerks to one another.  This includes respecting the constraints of the schedules of individual team members.


When it comes to choosing your team project, you're looking for a project that (hopefully) has these qualities:

• Popular: look at how many downloads its software has each month and how active its user and developer forums are.  If it's barely surviving or flat-lining, you don't want it.
• Vitality: check out the project's statistics.  The often include the number of new code contributions that have been made, and the number of new releases that are created each year.  All these are measures of a project's vitality and therefore show its receptiveness to the addition of newcomers.
• Growth Potential: don't go with projects that have matured and plateaued.  They may have a large user base and deliver a lot of value, but they don't provide newcomers with an opportunity to make an impact.
• Welcomes Diversity and Promotes Contributions: go for projects that are open communities with lots of opportunities for newcomers, not the close-knit group of buddies with a lot in common.
• Enjoyable: the project, not your class grade, should be the motivating factor for choose a project.  Chances are that choosing it because it's what your instructor would find fascinating isn't a good enough reason to work on a particular project.  Pick something that you're interested in and will be excited about working on it every chance you get.