How to manage your department
From Post-Apocalyptic RPG wiki
This article describes how lead developers manage their specific departments.
The mysterious lead developer
A lead developer is a developer of a department who takes a lead role in guiding the efforts in a specific field. Lead developers usually don't get appointed; it's an informal role developers decide to accept by stepping up. While this is not how it works in most commercial software projects, informal leadership is quite common in open source projects. This article was written for the developers willing to play a larger role in PARPG development by guiding the efforts in one specific development department. These are the common tasks lead developers should be prepared to take care of.
Here's the good news: micro-managing every possible contributor in your department is neither needed nor desired. By maintaining a set of getting started articles for new developers at the wiki, it will be easy to bring most contributors up to speed without spending much time on personal coaching.
Wiki editing guide
As the department-specific documentation resides at the wiki, being familiar with the basics of wiki editing is essential for these kind of tasks. FIXME
Common articles types
There are a set of common articles that are essential for every development department. That means that every department should have customized versions of these article types for their contributors. A lead developer should ensure that these essential articles are in good shape so that interested contributors have an easy time to pick of important concepts.
How to contribute
This is the most important article type for every development department. How to contribute articles list all important information a contributor in a specific department should be familiar with. The how to contribute articles just give a short introduction to these concepts and link to separate articles that explain the concepts in detial.
While there is a global project glossary, that contains terms that are important for every developer, every department also maintains a separate glossary for their field of work. Make sure that your department's glossary explains all the relevant terms to make communication in the department a breeze.
How to use SVN
These articles describe how Subversion is utilized as version control software by the department. This includes department-specific version control workflows, e.g. where specific code or assets should be stored in the source tree.
How to use Trac
These articles describe how Trac is utilized by the department. This includes department-specific ways of working with Trac tickets.
These articles contain a list of tasks that the developers of a specific department are currently looking into or working on. These lists are meant as an easy way to let the other developers of the team know who's currently working on what. Maintaining such lists eases communication and collaboration in a department and between different departments.
Idea dump articles are utilized by the different departments to keep their department starting pages clean. The idea dumps can be used to dump notes at the wiki and flesh out work in progress articles. Once the articles have been fleshed out in detail, make sure you properly categorize them and remove them from the idea dump article.
Department-specific articles & categories
Besides the common article types that are essential for every department, there are also articles and categories that are unique to each development department. E.g. the programmers will have documentation how unit testing software or code documentation is used in the department, the graphics artists will have a bunch of department-specific asset pipeline articles, explaining how to create new assets and how to get them into the game. These articles can be often grouped into department-specific categories.
E.g. the graphics department might have a bunch of different workflow articles how to create 3d models, how to create 2d interface art, etc. Nevertheless all of these articles can be grouped into one common "Graphics asset pipeline" category. By using categories for department-specific article types it will be easier to easily find all articles of this type, ensure consistency of these articles and to maintain them.
Department-specific categories should be implemented via Mediawiki templates. If you need help to set up new templates/categories for your department, get in contact with the project management department at IRC or the forums. They have the experts in the field for these tasks.
While good project documentation is a great way to get contributors up to speed, providing personal guidance is still needed occasionally. This kind of personal guidance will often take place at the forums or the IRC channel.
Monitoring the forums
The forums have department-specific subboards where contributors might ask department-specific questions from time to time. You can subscribe to specific subboards to ensure that you don't miss important new threads and posts. When questions are asked at the forums, you might be able to just give a short explanation and send the contributor to a more detailed wiki article about the topic. In case the wiki is lacking information on the topic, you should consider adding the requested information to an appropriate place at the wiki.
PARPG does heavily rely on live communication in places. While time zones work against us due the distributed nature of the project, IRC communication is still almost as useful as face to face communication.
Providing starting pointers
The IRC channel will be partially used in the same way as the forums: contributors will pop up in there and ask question how to get started. Keep a friendly attitude and give them some pointers how to get started. Linking to the how to contribute article of your department will often already be sufficent. Especially if the article is in good shape and covers the most essential concepts contributors should know about. If IRC users request information that hasn't been wikified yet but is essential to the department, add a note to your current tasks to wikify this information down the line.
IRC is also used for brainstorming, both between developers of the same department, as well as between developers of different development departments. Brainstorming is a great way to flesh out concepts in an iterative and creative step by step process. Getting used to brainstorming can take some time and will require a certain amount of openness of participating developers. Some contributors in your department might be rather shy on IRC, sometimes caused by the language barrier; not everyone on the team will be a native speaker. You can encourage contributors to be more open by asking them what they're currently working on or looking into. That's often a great starting point for further discussion and brainstorming. In case a developer is very shy on IRC, you can consult the project management department on advice what could be done about it. At the end of the day, there will be always a small percentage of potential contributors that have a different mindset and communication guidelines, that might not be compatible with what is required to contribute to an open source project. See conflict resolution below for details.
First of all, this conflict typology is mainly based on advice given in this video. In case you haven't already seen it anyway, watch it. It's prolly the best introduction to problems you'll encounter in open source and volunteer software projects. It's also full of rather funny anecdotes, so there is no good excuse to not check it out right away!
Anyway, back to topic: there are a bunch of possible conflicts that can arise in open source projects. In projects with a healthy project culture, most lead developers of different departments will have a somewhat coherent mindset so conflicts will not that often arise between different lead developers. But it's rather common that interested contributors, who are new to the project, will bring up a challenges that the project has to cope with. As a rule of thumb: we give interested contributors the benefit of the doubt. Most interested contributors want to help the project grow and flourish, but they need some guidance to get started. This doesn't rule out that some obvious trolls will pop up on IRC or forums from time to time. These trolls should be excluded from the community to protect the healtiness of the project culture.
Here are common conflict types that you might encounter in your department. Keep in mind that these are conflict archetypes; combinations of these conflicts are quite common in reality.
Workflow conflicts are caused by developers not following the established and agreed upon workflows of a department. This might not even be their fault: workflow documentation might be outdated or they have simply overlooked an important workflow article. In case a department-specific workflow article became outdated, add a note to your current tasks to update the article and let the contributor know (in a friendly way) how the workflow is intended to work.
Attitude conflicts are caused by developers not following the established and agreed upon communication guidelines of the project. Furthermore intentionally ignoring established department-specific workflows falls into this category as well. If somebody is ignoring communication guidelines and intentionally ignoring established workflows, give them a friendly pointer about it. In case they're not willing to adopt agreed upon project standards in the long run, they should be asked to leave the community as they will do more harm than good to the project.
Sometimes it's hard to judge if somebody has an attitude problem or if you just don't get along with him so well personally. In this case it's a good idea to get in contact with the other lead developers to get feedback on the behaviour of the developer in question. This feedback should be exchanged over private communication channels. Getting feedback from other lead developers will help to ensure that attitude conflicts are judged on a more objective basis.
Impatience conflicts are usually a mix of workflow and attitude conflicts. Change in open source projects takes time; you can't expect that a proposed substantial, larger change will be implemented in a short timespan. While smaller suggestions can be taken care of right away most of the time, larger changes usually affect several departments and fields. A substantial code or infrastructure change often requires that project documentation gets updated in several places and that these changes are communicated to all affected departments. Lack of understanding for this part of the open source development process can lead to impatience conflicts.
Impatience conflicts can arise in a bunch of different fields and can be usually spotted by the demaning tone of questions asked:
- Why isn't my 3d model in the game yet?
- Why didn't you ship the release last week?
- Why hasn't been my patch reviewed yet?
- Why haven't you made the switch to <insert infrastructure software of your choice here> yet?
Level of commitment conflicts I
It's natural that open source projects have contributors with varying levels of commitment. Nevertheless every contributor shouldn't expect substantially more commitment from others than he's willing to commit to the project himself.
Level of commitment conflicts II
Sometimes you'll have newcomers on the team who are overanxious to contribute and make the project happen. They commit to the project to such a large degree that they're disappointed soon that others don't do so. What they fail to see is that the others are contributing since months or even years to the project. Large scale open source projects are marathons. There is nothing wrong with a sprint to get started with the project, that's actually appreciated. But don't wonder that other developers jog around most of the time. They do this on purpose to avoid exhaustion so the they can contribute over a larger period of time instead of collapsing and disappearing once the initial overenthusiasm is gone.
Type of commitment conflicts
Writing code is more fun than writing unit tests. Implementing new features is more fun than debugging problems. Nevertheless working on project and code documentation, writing unit tests and debugging problems are essential parts of the software development process. Type of commitment conflicts arise when some developers are primarily focusing on the more fun aspects of development while leaving essential (but often slightly boring) work to others.
Experience conflicts are caused by developers lacking experience to contribute to the project in a substantial way. While developers of different experience levels are contributing to the project, a certain minimum level of experience will be required to contribute to the project without slowing the other developers down. If a developer requires a lot of personal tutoring without any substantial contribution coming back to the project and the situation doesn't seem to improve over time, get in contact with the project management. There are a bunch of possible options in this case; e.g. pointing them to easier to tackle starting tasks. If a developer simply lacks the required minimum experience to contribute to the project, we shouldn't be shy to let him/her know in a friendly way.
Communication conflicts are often special cases of experience and/or attitude conflicts. The language barrier is often the main problem. Not everyone on the project is a native speaker, but a certain level of experience in written English is essential to contribute to the project. If somebody can't make himself/herself somewhat clear, working with the developer on the project will be a frustrating experience and will slow down the entire team. In this case we shouldn't be shy to let him/her know in a friendly way. PARPG is not a language course project.
System requirements conflicts
While this doesn't happen very often, these type of conflicts tend to be slightly emotionally painful to resolve. System requirements conflicts arise when a talented contributor shows up, whose contributions are hindered by the system he uses or the infrastructure he depends on. Here are a few examples you might encounter in reality:
- Your software runs too slow on the contributors system so he can't reasonably test it
- Used infrastructure software (e.g. an SVN client) isn't running well or running at all on the contributors system
- He doesn't have access to broadband internet but your project heavily relies on a stable broadband connection for communication and version control
The bad news is: you often can't address these conflicts. Downscaling your project infrastructure and coming up with alternative workflows for contributors who suffer from system requirements conflicts are an option in theory. In reality, that's often a lot of work and might not be worth spending your time on.
Blackmail can be seen as a special type of level of commitment & attitude conflicts. Because even before somebody considers to get involved in your project, he will propose (often in a demanding tone) that you implement certain changes; either to the software itself or the project infrastructure.
Here are some examples:
- I would contribute as a writer, but you would have to go for this awesome storyline I wrote.
- I would contribute as a game designer, but you would have to turn this into 3d shooter heavily inspired by <totally unrelated game>.
- I would contribute as a programmer, but you would have to use git for version control.
- I would contribute as a programmer, but you would have to rewrite the game in C++ first.
- I would contribute as a graphics artist, but you would have to buy me a copy of Maya/Photoshop.
- I would contribute to your project, but you would have to port it to DOS/Solaris/Haiku/<insert esoteric operating system of your choice here>.
What all these claims have in common: they will result in a lot of work for you. The good news is (or the bad news, depending on how you look at it): the people who bring up those suggestions are usually not willing to help out with implementing these changes. So it's safe to ignore them. They might bring up worthwhile suggestions nevertheless, but you should never implement a change just because somebody blackmails you that he won't consider to contribute to the project otherwhise.