Communication

From Post-Apocalyptic RPG wiki

Jump to: navigation, search

Established workflow.png This article covers an established workflow.

Established workflows have been discussed among and agreed upon by the development department(s). They should serve as documentation how these workflows are successfully utilized in the project.

The purpose of this article is twofold:

(a) Outline the basic principles that apply to developer <> developer & developer <> community interaction.

(b) List the various communication channels that are utilized by the development team.

Contents

Communication channels

Blog

  • URL: http://blog.parpg.net
  • Keeping community and developers 'up to date about the progress of the project
  • Way to reflect PARPG development

Forums

  • URL: http://forums.parpg.net
  • Discussing concepts that have been already fleshed out at the wiki and are ready for feedback by other developers
  • Discussing concept that might be worth fleshing out but you would like to get some feedback from the other developers first before investing a larger amount of time
  • Community interaction.

IRC

  • For details, see: IRC
  • URL: http://irc.parpg.net
  • Real time developer communication.
  • Easiest way to stay in regular contact for the currently active developers
  • Community interaction

Planet

  • URL: http://planet.parpg.net
  • Easiest way to stay up to date about the project
  • Aggregates new posts at the blog and forums, SVN commits, new trac ticket/comments and wiki edits in one central place

Trac

  • URL: http://trac.parpg.net
  • Tickets ready for implementation
  • Bug reports by developers as well as others

Wiki

  • URL: http://wiki.parpg.net
  • Place to store all kind of project documentation
  • Discussion of concepts should rather take place at the forums. The wiki talk page functionality has therefore been deactivated. You can still use your personal talk page for storing notes as it's not affected

Glossary

We maintain a project glossary for agreed upon terms, as tehey eases communication and help us to avoid misunderstandings.

Communication guidelines

  • Be polite. Politeness is a key to understanding each other. No one will bother to understand what you have to say if you annoy him/her. Don't be oppressive, don't criticize "all in general". You can be brilliant, but while not being polite you will not communicate nothing to no one.
  • Try to react not too emotionally. Never loose your balance. Don't get angry. Keep discussion calm, quiet, and as close to the topic, as you can.
  • Respect other people and, most important, their time.
  • Be explicit and comprehensive. When you're describing something, do the rest of the community this small favour and actually describe it. Imagine we don't know nothing about what you want to say to us.
  • 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 PARPG developers.
  • Criticism is encouraged in general. Constructive criticism is strongly encouraged on the team but even listening to feedback by users that appears 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 preferred 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.
  • Assume good intentions. A little bit of psychology goes into this one, but just because you are having a bad day, doesn't mean that someone is giving you attitude. If someone points out something you should be doing that you aren't, or something that you are doing that you shouldn't, assume that they are acting in best faith, and not maliciously. It usually is the case, and doing so eases many potential issues.
Personal tools