Developing Cubes

This chapter describes some guidelines how to develop and contribute to the Cubes.

General

• Provide mechanisms, avoid forcing policies. Any policy should be implemented in a way that it might be replaced by an alternative or custom policy.
• If you are puzzled why is something implemented certain way, ask before complaining. There might be a reason that is not explained and that should be described in documentation. Or there might not even be a reason for current implementation at all, and you suggestion might help.
• Focus is on usability, simplicity and understandability. There might be places where this might not be completely achieved and this feature of code should be considered as bug. For example: overcomplicated interface, too long call sequence which can be simplified, required over-configuration,...

Backends

Implement at least:

• aggregate
• facts

New or changed feature checklist

• add/change method

• add docstring documentation

• reflect documentation

  • are any examples affected?

• commit