Developer's_Guide

• Diving into Glou Development
• Contributing
• Guidelines
  • Communication
  • Patches / Repository Access
  • Code
    • C
    • Python
    • Bindings

Diving into Glou Development

• The place for you, as a developer, is the Development Page. Here you can learn everything about the architecture of the Open Gaming Network and the Glou components.
• Have a look at our Repository Page. There you'll find instructions on how to get the Glou code.
• Look through the code and get some feeling for it.
• Every Glou component has a README.txt. Read it :) .
• If you have questions, ask!

Contributing

If you'd like to help with the development of Glou join our mailinglist. Simply introduce yourself and tell us what you would like to work on or ask what there currently is to do.

Note: our community has established some important guidelines. Please read them carefully and follow them when working with Glou.

Guidelines

Communication

The important thing to remember is that every decision is made on the mailinglist. Gathering of ideas and discussion can happen over every medium, but a summary of all results should then be posted to the list, so the whole community can take part and decide what to do with the idea.

Talk about your plans. Let everyone on the mailinglist join the discussion about your idea. Don't design / code things alone in the back room. This helps to get your ideas / code to be accepted by the community and also helps to prevent conflicts, i.e. two people working on the same problem.

Patches / Repository Access

If you have fixed a bug or added a feature you should send a patch to the mailinglist (bzr has a nice feature for that). If you've handed in some patches, everyone is content with your work and you follow our guidelines you'll get write access to the repository.

If you want to start a new component or a new larger feature, create some overview and architecture description for it. After the idea has been discussed you may get write access to a private branch in the repository. When everyone is content with your work and you follow our guidelines you'll get full write access to the repository.

Code

The most important thing here is consistency: look at the existing code and use the same coding-conventions for the things you write.

• Tabs: spaces-only, 4 characters

C

• Coding Style: K&R
• Object-oriented: Pseudo-OO
• Documentation: Doxygen

Python

• Documentation: Epydoc

Bindings

Creating bindings is a balancing act. The bindings should be as close as possible to the original API, but at the same time should feel natural in their language.

• Don't add extra functionality or rewrite major API parts.
• Users of the original API should instantly feel at home when using the bindings.
• Stick to the idioms of the bindings' language.

[Category:Ideas]