Making Mods/Working As A Team
Working as a Team
If you've managed to get this far you are doing well. You have managed to pull a team of people together to work on a mod. Your biggest problem now, apart from finishing the mod and getting people to play it, is keeping your team enthused and together.
Communicate!
Good communication is absoloutely key. The better you get on as a group of people, the stronger your team will be when things get tough. This is particularly important for mod teams as they are very rarely co-located.
Set up a fixed same time, same place meeting at least once a week, two or three times if you can manage it. These fixed meetings should be used to report progress and discuss the inevitable problems that crop up. Keeping these sorts of meetings short is a good idea, but make sure it's either over IRC or voice over IP. A forum is not a good place for a meeting.
If you have your meetings via IRC, make sure at least one person keeps a log of the meeting. That way agreements, actions, and changes to the mod are recorded. If someone doesn't have the log make sure it gets e-mailed to them.
IRC can be very "spammy". If you are having a meeting then show some restraint. Make sure that someone has finished "typing their piece" before leaping in with comments. While the team is fairly new, never ever insult someone, even if it's in jest. Written text is often mis-interpreted. Equally, if you think someone is having a dig at you, keep your fingers off the keyboard and let it pass. By all means follow up any problems you may have with an e-mail, but be restrained. Your "attacker" was most likely not intending to cause offence. As you get to know each other and develop some "trust" this will become less of an issue.
If you use Voice-over-IP (VoIP) to have your meetings, make sure you keep track of the discussions that occur, and make sure that a written record gets sent to everyone involved in the mod – even if they missed the meeting.
E-mail conversations should be avoided where possible. They are time consuming and very wasteful of resource. You will save yourself much pain and frustration if you simply organise an ad-hoc IRC or VoIP meeting. A discussion on a forum is to be preferred over an e-mail conversation.
Although forums are very poor for meetings they are great for posting meeting records, progress, and non time-critical questions and musings. Forums are well suited to the discussion of a non time-critical feature for the mod. If you do use a forum, make sure everyone on the team uses it. A dead development forum is pointless. If you have a question or idea that doesn't need an immediate answer then a forum is a better medium of communication than a bunch of e-mails flying backwards and forwards.
If you team members are going to be on-line at different times (because of differences in time zones) then a forum is generally a more practical medium for communication than IRC or VoIP. In this case team members that have a question about a specific problem they can post it on the forum in the knowledge that by the time they get back on-line the following day some sort of answer will be waiting for them.
It's well worth the teams effort to post little individual progress updates on how things are going. For example your coder might post an update to say that the primary fire for weapon X is finished. These small updates may seem somewhat pointless, but they indicate that progress is being made on the mod. There's nothing worse than working in a vacuum wondering if anyone else is working on the mod or whether it's just you. Lots of small updates can also provide an element of excitement as well as it indicates that things are being finished. One of the nicest things about the use of a forum is that you have the time and space to frame your thoughts in their entirety.
And finally a warning. If your team fails to communicate, it's already dead.
Some Things to Avoid
Do your level best to avoid adding features to the mod while you are writing it. New features and ideas are bound to occur to you as the mod develops. This is a natural and good thing. However, you should observe the following rules.
- Make sure that any changes to the current mod spec are agreed by all members of the team.
- Only add new features if you cannot defer them to a later release.
Many projects fail simply because the number of excellent features required grow faster than they can be written. When this happens the mod never gets finished.
Respect the other team members responsibilities. In other words, don't do their work for them. At best they'll appreciate the extra help. At worst you will be duplicating work they've already done and create bad feeling. The most likely outcome is that they'll be a bit annoyed that you've taken "some of their turf". There are very few reasons for ever picking up another team member's work and responsibilities.
- They have explicitly requested from help
- They have gone on holiday and know that you may pick up some of their work (because you asked first)
- They have quit the team (hopefully this won't happen).
And never ever tell another member how easy something is unless you know exactly what you're speaking of. And don't overestimate or underestimate someone. I know that's quiet difficult but overestimating someone might put too much pressure on him/her and underestimating might give him the feeling of beeing unimportant or worse, he's thinking of you as a know-it-all.
Attitude is Everything
The team's attitude to the mod and each other is fundamental to the success of the mod. It is vitally important to attempt to be positive about the mod at all times. Especially in the later stages of the mod when the team will be sick of the site of it.
Be flexible with each other. Don't get hung up and stressed with a team member who requests a couple of weeks off. Everyone needs time to let their batteries recharge once in a while. Just because you can work non-stop for 20 hours a day every day for seven days a week doesn't mean everyone else can. Allow team members some real life. It will help keep the team healthy.
Don't be possessive about your particular set of responsibilities or deliverables. If you are a week late delivering something, don't get upset if the team asks if you need some help. Before you flatly refuse the offered help consider the offer carefully. It may be that you could actually use the help.
The team should try and share as much information with each other as possible. This provides the team with an excited buzz as all team members can see progress being made, and work happening. It also means that the team has the opportunity to spot problems and hitches in progress as soon as they start to appear. If you have more than one developer working within the team then at the very least the developers should walk each other through their code.
It's well worth putting some time into cross training each other. A team of generalists who have specific areas of expertise is in a much better position to survive the loss of a team member than a team of narrow skilled experts. Having team members cross train each other will not only bring the team closer together but provide an avenue for people to try things outside of their immediate area of expertise. Besides which, everyone likes learning new stuff.
Summary
- Communicate.
- Be flexible.
- Don't get possessive.
- Communicate.
- Respect other people's areas of responsibility.
- Share all information as much as possible.
- Consider cross training.
- Communicate.
Discussion
Mychaeel: I can not understand where that apparent antipathy against using forums for "team meetings" in the first paragraphs comes from. Actually, I'm much more disinclined to use IRC (shortlived, spammy, unstructured, unlinkable) or even Voice-over-IP (not even possible to keep a useful record). Forums, on the other hand, encourage thoughtful posting, structure, allow for posting additional media such as images, are searchable and are kept around for future referencing. – I'd like to have this matter discussed before changing anything about the text itself.
El Muerte TDS: there's also something like a mailig list. It's just not one or the other, using more tha one medium is often better, Forum\Mailing list\NNTP and IRC is a good combination. Sometimes you just fast responses. VoIP is juist chaotic for meetings.
EntropicLqd: If you don't like it change it. The reason I don't see a forum as being a good medium for a "meeting" is because it doesn't fit my concept of a meeting. To me a meeting is a short-lived and immediate discussion between two or more people about a particular subject. It's the word immediate in my definition that precludes the use of a forum for a meeting.
Mychaeel: EntropicLqd, I like to make changes an educated decision, so I like to have a discussion about what I feel needs a change. Otherwise I'd just change it. 
– Why is "immediate" such an important thing? I don't see a mention of that term in the text above either; just a direct transition from "you must communicate" (which without any doubt is true) to "meeting" to "forums bad, IRC good." If that's not what the text means to express, it's at the very least misleading.
EntropicLqd: Immediacy is the very core of a meeting to my mind. That immediacy and "real time" response is what separates a "discussion" via a forum or e-mail (or whatever) from a "meeting". I'm treating them as two distinct concepts. So, because of my requirement on immediacy for a "meeting" it cannot take place effectively in a forum. Also, surely part of the requirement of a meeting is that all of the meeting members have to be present and able to communicate at the same time. Would you call our comments a meeting? No - because it's not. We are not "meeting" as such. We in a discussion with each point occuring at a distinct point in space. The text above starts with a discussion about meetings. You can't have a meeting in a forum - but you can have a discussion. The text certainly doesn't preclude the use of forums - and even encourages it in some cases. All it really says is that a forum is a bad place for a meeting - which to my mind is a true and valid statement.
To be fair, when I wrote the page I simply threw down a bunch of stuff that seemed sensible based on experience gained in the work place. I've never been part of a mod team (there is no requirement for someone who can't even guarantee an hour a night) so my musings above could be complete rubbish. Looking at the page now it could probably do with some sub-headings splitting out the various forms of communication and discussing the things they are good for.
Mychaeel: In that case, I argue the importance of having a meeting to discuss things. The emphasis is on discussing things, and I think that forums are by far better suited for that than IRC or VoIP. Granted, it's a different matter if you actually can meet physically in real life – but meeting in person also opens the opportunity of using many more communication channels than just speech.
In conclusion, I'd like to have emphasis put on the important of discussing and communicating in a team by whichever means is best suited for it, but not necessarily of conducting meetings for that purpose. Different communication channels such as forums, IRC, VoIP can be mentioned with their respective advantages and disadvantages.
RegularX: On the FH Team we use group emails about 90% of the time, with emails usually 2-3 times a week. We catch up personally on AIM and IRC from time to time but with people across huge time differences and two continents, it's not really feasible (or necessary) to get everyone talking at once. Communication is key for both keeping everyone up to date with progress and also push the development along, but how that communication takes place is probably up to the team.
