I have started hacking on a theme I will push to my own Github account, fine, but I have just bumped into an issue where I want to change the layout of the dashboard but dashboard/templates/dashboard.htm has some hardwired styles... now do I jump out of the self contained theme area and change a non-theme "internal core" template or do I try to submit a patch and argue for the change to dashboard/templates/dashboard.htm so I can modify my themes CSS file instead. Easiest is to hack the non-theme file directly and move on, but, obviously that change will be overwritten by a future update. Okay so next step is to see how do I lobby for a non-theme change and submit a patch? I don't know yet and that is what has led me to this thread by searching (this somewhat cruddy forum software) for an answer to how to contribute for a first time contributor.
Frankly I still don't know how to lobby for this simple change nor how to contribute a patch and even if someone made my life so much easier by posting precise howto links I'm not sure I want to spend the time with antiquated forum/tracker software to be bothered.
Everyone is welcome to contribute to ispconfig as described many times here in the forum. If you wish to submit a patch, send it by email to dev [at] ispconfig [dot] org. If you wish to contribute regularily, then send a email to the above address to request a svn login. There are many tools available to work with svn repositores, you can browse them and integrate them directly into all major code editors.
It's up to you guys if you want to help to improve the ispconfig project or work against it by splitting the development without contributing back.
Why is it not so easy to contribute?
As a general note why we are conservative regarding contributions: we tracked the time that it costs when a core devloper develops new a feature and that it costs to fix contributed code until it really works on all platforms, single and multiserve etc. (as most contributurs dont think about that) and does not breaky any existing features or extension. An example: We got a contribution of a new library that is used all over the system because the contributor thought that our old one was not "modern" enough, while the old one worked fine and was stable. At the first glance, the new lib worked fine so we included it, on the long term, more and more unpredictalbe behaviour occurred in various subsystems which at the end pointed to several design flaws in the new lib. Writing a modern version of our libray myself would have taken me about 2 hours, debugging all the issues in the contributed lib caused me and some other core devs about 15 - 20 hours of work till now. So basically this contribution costed the dev time that it would have taken to implement the top 2 or 3 most voted feature requests in the bugtracker. This is just one example but in fact the development of isponfig slowed down the more contributions we got as it binds the core devs to fixing issues only as the contributors left their code alone or when it gets "ugly" with debugging issues seriously in their code they were not available anymore. ISPConfig is not as simple as a cms system or similar software, ISPconfig is a ecosystem consisting of many server services were a minimal change in permissions of one file may bring a completely different subsystem down, so it requires a deep knowledge of Linux systems, programming and the way ispconfig works to contribute code to parts that are not themes or translations. So when we migtrate to a platform were we get many contributions from devs that we dont know their ispconfig specific knowledge, then it might destabilize the project and brings development to halt.
@cfoe: It would be great if you would submit your theme to our official SVN as well when it is finished.