Index: trunk/doc/contrib.html =================================================================== --- trunk/doc/contrib.html (nonexistent) +++ trunk/doc/contrib.html (revision 7310) @@ -0,0 +1,70 @@ + + + + + sch-rnd - contribution + + + + + + + + + +

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. + +