Main | Doc & Knowledge pool & Tutorial | Current state | Events & timeline | sch-rnd

# sch-rnd - contribution

If you are interested to help out, please contact the lead developer.

## Contributing as a user

Using sch-rnd in production and just reporting bugs is already a huge contribution.

We also have a list of tasks that can be contributed by users.

More dedicated users can join in scheduled, systematic testing. Such testing is split up into independent chunks that each can be done in an hour.

Even more dedicated users can join developing the documentation.

None of the above requires or assumes any programming skill.

## Contributing as a developer

The project is lead in an autocratic way by Igor2.

Developer freedom taken away:

- the basic concept of sch-rnd is set and won't change
- the toolchain is chosen, and won't change; the usual hot topics: svn, scconfig, C.
- don't add code that restricts usability for others; add code that increases usability for some; thus prefer to add code in plugins!

Developer freedom promptly granted:

- svn commit access from day 0
- work together in trunk/, not alone in a branch
- sch-rnd has a strong plugin support; want to implement a strange/controversial feature? In a plugin, almost anything goes
- especially in plugins, work on whatever you want, even if noone else needs that feature

Coding style/indentation: there's an unified style in core and core plugins. If you work on those parts, try to stick to it. If you are working on a new plugin, it's still the preferred style but you can use a different style. However, the rule is that if someone else starts hacking that part too, he is allowed to convert the code to the unified format; but unified format can not be converted to anything else. So it's a one way process which long term grants unified style while not demotivates a plugin developer by forcing a style on him in the early, "when the bulk of the code is written" phase.