Rules and Guidelines

From Thrive Developer Wiki
Jump to navigation Jump to search

These are the rules relevant to development. For rules relating to the general community, see the FAQ on our community forums.


General Rules

  • Respect other members. This means that any personal attacks are unwelcome, and any language that is purposefully inflammatory or derisive is prohibited.
  • Stay on topic. Please only post information in threads that that information is pertinent towards, and try to discuss issues tangential to the thread's main purpose as little as possible.
  • Act professionally. It's fine to have personality, but we want to run an efficient forum where ideas are exchanged quickly without too much superfluous chit-chat.
  • Leave the dead to rest. Please don't post in threads that haven't seen any activity in the past year or so. If you want to start discussion on them again, first message a moderator.
  • Think before you post.

Things to Remember

  • We are a worldwide community. Many of our members speak English as a second or third language, so be accepting of misspellings and imperfect grammar. At the same time, try to keep your own posts as coherent as possible, so that there is minimal misunderstanding between members.
  • There is a hierarchy of command. When there is a question or dispute, don't be afraid to summon a moderator or team lead to the thread to resolve it.
  • Thrive has been around for a while. We've had lots of ideas, and lots of those ideas didn't make the cut, or are being put on the back burner to be dealt with at a later date. If we've already thought of your idea, or seem to dismiss it fairly quickly, don't be offended. We've probably seen it before.


As well as the above rules, we have policies in place which we hope will make your experience contributing to Thrive more enjoyable.

Since this is a (mostly) volunteer project with no rigid team structure, you are in no way obligated to do anything. Life and work take precedence at all times, and you’re entitled to all the downtime you wish. We won’t stop you leaving the project for good if you feel like it.

However, be aware that sometimes the work of others will be dependent on your own. If someone is waiting for you to finish a feature so they can get to implementing their section and you disappear without warning, while you’re completely within your rights to do so, it can pose a problem for the project as a whole. If you’re not expecting to be able to finish what you’re working on, please let us know so we can work around it.

You’re free to work on what you want, within reason. Fed up with hitting your head against a brick wall with one feature or problem? Switch to another. Though if you applied as a programmer and switch to working on graphics, we would like the assurance that you do know what you’re doing with graphics. In a more extreme example, a musician who decides to contribute to theory discussions should be wary that their opinions in this area will hold far less sway, at least until they can prove they have the necessary theoretical knowledge.

Every contribution will be reviewed by a seasoned member of the team. We reserve the right to decide whether any contribution is of the standard we’d like, but if it isn’t we’ll give you advice on improving it. Team leads will always have the final say.

Though we never want to use it, team leads and moderators also have the ability to revoke someone's access from a particular online resource if they're misusing it, breaking the above rules or being deliberately difficult to work with (we'll give you a warning first). We only have this policy in case of an extreme situation, so we apologize if it sounds a little authoritative.