We employ a set of project guidelines that developers are expected to adhere to. They are meant to keep our project manageable as opposed to slowly spiraling into chaos and certain oblivion. If you're following the Getting Started guide, you've already encountered some of the guidelines, disguised as settings on the Configuring Eclipse page. They won't be mentioned here again.

The project guidelines can be divided into two broad categories: management guidelines, and coding guidelines.

Management Guidelines

We know the term sounds business-y, but just bear with us for a minute. These are our guidelines:

• We have a weekly project meeting to discuss KIELER issues and to check up on what everyone else is doing. KIELER developers are expected to attend the meeting, if at all possible. You're also welcome to give a short demo of cool new features you've developed.
• We have a developer mailing list that all KIELER developers are expected to be on. If you haven't signed up for it yet, do so now. The mailing list is used to announce changes that affect other KIELER developers.
• We use Git as source code management system. In order to understand the high-level workflows involving clones and branches, read the Source Code Management page.
• We want our code to be well-designed and well-written. To help ensure that, we have a review process, designed to have other people look at your code and suggest improvements as well as learn from it. Take the opportunity to get some valuable input!
• KIELER is an experimental and fast-changing research project, so we don't document it with anything approaching professional standards. However, there are two sources for information: bachelor / master / diploma / doctoral theses about specific parts of KIELER, and this Wiki. If you have developed some complex feature, please consider adding documentation for it to the Wiki. For development work done as part of a thesis, this is pretty much mandatory and will go into the thesis's appendic.

Coding Guidelines

The coding guidelines are guidelines that we cannot enforce solely with the Eclipse configuration:

• When contributing to the KIELER user interface, be sure to respect the Eclipse User Interface Guidelines. By the way, Hallway Usability Testing is a great way to make sure users understand the UI you're designing. Just draw a sketch of your dialog design on a piece of paper, visit a few offices and ask people what they think of your design, how they would use it, and whether they understand it. You're almost certain to discover a few problems with your design that you wouldn't have discovered until after you've written a whole lot of code.
• The core parts of KIELER can be and are used outside of the Eclipse framework.