Fun reading the thread. You guys were getting all 'het up' before there were even decisions to be made! But I do sympathise. Its exciting, and I too drink too much coffee on occassion I was glad to see things coming together by this third page, but I still have my fingers crossed that you can really do some work together. Its going to take a lot of compromise I should think.
Of all the positions argued in the thread, the thing that I most resonate with is: Get something working ASAP and build from there, adding features as people get motivated to do so. That is by far the easiest group-programming model I've ever worked with. Tasking people to do X, Y, and Z and hoping they come together to spell SMAC is something better left to teams working in physical proximity with tangible leadership and proven skillsets/expectations.
Actually, as usual, I pretty much agree with everything Blake has to say, both from a programming pov, from a group project point of view, and from a 'To Clone or to Adapt' pov as well. All three are part of the same equation which looks like this:
Possibilities A-->Z * Factor X = TangibleProgress
That X is delicate: Make working together on this as easy as possible; Make small incremental changes where possible rather than large wholesale ones. Keep a working version rather than dissassembling and reassembling, and by all means don't hold yourselves to cloning SMAC as the first priority and tossing out anything 'unclean'.
Just my 2 ecs. I may or may not have some time to give this, but am being very careful not to make commitments I can't follow up. And btw, Python + XML == Dreamy coding environment! This sounds like great fun, especially being that those two (script-lang + markup) are some of the best languages for non-coders to meddle with. It should be that everyone will be able to take a stab at the coding (hrm....maybe that's not such a good thing after all!).
-S
Of all the positions argued in the thread, the thing that I most resonate with is: Get something working ASAP and build from there, adding features as people get motivated to do so. That is by far the easiest group-programming model I've ever worked with. Tasking people to do X, Y, and Z and hoping they come together to spell SMAC is something better left to teams working in physical proximity with tangible leadership and proven skillsets/expectations.
Actually, as usual, I pretty much agree with everything Blake has to say, both from a programming pov, from a group project point of view, and from a 'To Clone or to Adapt' pov as well. All three are part of the same equation which looks like this:
Possibilities A-->Z * Factor X = TangibleProgress
That X is delicate: Make working together on this as easy as possible; Make small incremental changes where possible rather than large wholesale ones. Keep a working version rather than dissassembling and reassembling, and by all means don't hold yourselves to cloning SMAC as the first priority and tossing out anything 'unclean'.
Just my 2 ecs. I may or may not have some time to give this, but am being very careful not to make commitments I can't follow up. And btw, Python + XML == Dreamy coding environment! This sounds like great fun, especially being that those two (script-lang + markup) are some of the best languages for non-coders to meddle with. It should be that everyone will be able to take a stab at the coding (hrm....maybe that's not such a good thing after all!).
-S
Comment