2008/1/19, Fred Williams <[EMAIL PROTECTED]>: > Fine a wiki for the developers and a web site are good ideas. > Developers may come and go and getting them up to speed on the project > requires documentation and possibly training. Internal communications > is vital and every developer should be in almost constant contact with > the group to make sure everybody's on the same project and knows what is > going on. This synergistic culture is vital to such a team. It's in > everybody's interest that all the other team members understand the > project perfectly. Time spent bringing a new member up to speed is not > wasted. A developer's bulletin board is essential. Well defined > standard interfaces for code is also essential and design changes must > be tracked and approved by the core development team. Things like that > ensure a solid program. > I could get behind a project like that.
Ok, so what needs to be done to get such a project rolling? The following is my opinion, and of course everyone is free to argue otherwise. ;-) When "planning" a project, I prefer to make an Assessment of the resources that I have available first, because I somehow like to be realistic about what really "can" be done instead of building castles out of air and then being disappointed that it did not work out. So, this "Project" seems to be about "Code", programming code and such. So, while there is certainly a lot of code already out there that can be reused, someone has to fit it together and someone has to fill in the missing parts. So this project will involve coding. So we need "Coders". This is how open source projects work, they need coders. There are many people with ideas, but someone has to code it and generally, those people are a scarce resource. So, in planning this stuff the first thing to find out is who are the coders, and what are they willing to do. Making big plans and then expecting outsiders to jump in and start coding is an approach that has proven not to work, at least as far as my experience goes. Maybe at one point outsiders will come and start contributing, but for that to happen, a solid core is needed, something that is of value to contributors. And btw. I also believe that making plans that reach too far into the future are very, very risky, especially if one relies on volunteers. Better make a small proposal for a well defined problem, for which a solution is immediatly useful. Then try to get it solved as fast as possible, before people loose interest, and then try to "infect" as many peer groups as possible with the solution to create an "eco-system" where the solution can sustain itself. Then fit that part into the big picture, and move on to the next little puzzle part. So, I am volunteering to do stuff, who else is? Cheers -Richard PS.: the discussion is distributed among the following mailinglist, so check the archives: https://www.bek.no/mailman/listinfo/piksel http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra -- Are you teaching the What and the How but without the Why and the When? _______________________________________________ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
