+
+If you are interested to help out, please contact me using
+ the live chat (CET daytime) or mail to:
+pcb-rnd (at) igor2.repo.hu.
+
+
Contributing as a user
+Using pcb-rnd in production and just reporting bugs is already a huge contribution.
+
+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 pcb-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
+
pcb-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.
+
+
+