Communication

From FIFE development wiki
Jump to: navigation, search

This article is outdated and is just stored for archive purposes. Archived.png

This article became outdated and is just stored for archive purposes in this wiki. There are several reasons why an article could become outdated. The development team may have decided to use a different concept or even the author itself felt that the article is not really up-to-date with the current development status of the project anymore.

Introduction

This article covers communication standards of the FIFE development team. Communication standards are a set of agreed upon norms how to communicate with other developers as well as with users. Furthermore this document describes the structures that are utilized for communication. The mentioned norms are not set in stone but are meant to be a guidance for new developers. They are of course open for discussion.

Communication standards

  • Honesty and transparency should be the basis of all team communication.
  • Every developer and user is encouraged to ask questions. The easiest way to address gaps in one's knowledge is to simply directly ask. Asking questions is not seen as act of being unaware but as expression of the will to learn and to educate yourself.
  • Feedback by developers and users is always appreciated, preferably worded in a constructive manner. This does not only apply to Public relations but also to any form of communication that involves FIFE developers.
  • Criticism is encouraged in general. Constructive criticism is strongly encouraged on the team but even listening to reviews by users that appear to be worded in a destructive manner can help us to spot issues. Recognizing and admitting problems is the first necessary step to resolve them.
  • Discussions are an exchange of rational arguments. If you fail to find a way to express your opinion as arguments, try to describe the rationale behind your feelings for or against something nevertheless.
  • Public discussion is strongly prefered over private discussion. All information that is exchanged via private communication between two individuals is not available to other developers; that's something we want to avoid! Use the IRC channel or the Forums instead of mailing other developers directly.

IRC

Advantages

  • Live communication is possible by utilizing IRC channels. This is often the fastest way to resolve issues.
  • Live communication helps us to follow key principles of our communication standards. It encourages brainstorming, exchanging arguments and asking questions that often would not have been asked as none of the other communication structures would have been seen as the appropriate place for them.

Drawbacks

  • Talking over IRC is no persistent way of communication. With the new IRC logging bot in place the situation has improved but it's not suitable for developers who took a break for a certain timespan to read through all the logs.

Proposals

  • The results of IRC communication should find their way to the forums or the wiki if a persistent discussion or documentation is intended. IRC is the main communication channel that is used in FIFE and it's the easiest way to effectively take part in the project.

Forums

Advantages

  • Forums attract casual visitors and are an easy way to give feedback or ask question.

Drawbacks

  • Forums are primarily meant for persistent discussions. Therefore they are not well-suited for consistent structuring of actual information.

Proposals

  • The results of forum communication should find their way to the wiki if a persistent documentation is intended. We've decided to move development discussion from the mailing list to our new forums. So far the majority of the developers seem to prefer forums communication over the old mailing list method.

Mailing list

Advantages

  • The Mailing list was used to notify all developers and subscribed users in the past.

Drawbacks

  • Mailing lists are often not the first place to look for information. Therefore it's unlikely that solutions that were posted on the mailing list will be found there later by people who run into issues that were already discussed at the mailing list.
  • The sourceforge mailing list suffers from occasional delays. That means that not all developers get mails that have been sent to the mailing list immediately. While this just happened 3-4 times over the last months it's annoying nevertheless and slowing down the discussions and can even create confusion (developers are not aware of ongoing discussions).
  • The sourceforge mailing list lacks an effective spam protection system. Mailing list subscribers get bothered with spam therefore. Furthermore cleaning the mailing list archives from spam takes time for the project admins as well.

Proposals

  • We've decided to send the mailing list into hibernation mode. Therefore you can't send messages to it anymore; the forums are now the place for persistent developer discussions.

Wiki

Advantages

  • Wikis are an almost ideal way for persistent project documentation. Wikis offer a number of tools for writers that help to structure information in an useful way.
  • The recent changes tool helps to keep track of all changes.

Drawbacks

  • Persistent maintenance is the most important way to guarantee a certain quality standard for the wiki over a longer period of time. Unmaintained and outdated (and therefore wrong) information does sometimes lead to even worse consequences than no documentation at all.
  • Wiki syntax is different to simple ASCII text. This complicates shipping documentation as text files with releases.

Proposals

  • Stick to our wiki as primary documentation platform.