User talk:Mstone/Commentaries/Releases 2

Sugar needs more centralized direction-setting than your average project? Not convinced, but I'll accept that for argument.

A priori, Sugar needs neither more nor less direction-setting than any other project of equivalent scope. Instead, OLPC needs direction-setting in order to realize the Sugar changes that OLPC and its partners want to see. A corollary is that the Sugar changes that OLPC funds and decides to ship may be different from the ones that other users of Sugar desire. I'm simply searching for good ways to work together given that premise. --Michael Stone 02:13, 28 May 2008 (EDT)

So how do you avoid people getting mad at you? Make it easy for them to do their own thing in their own sandbox; make it easy for them to understand how the decisions get made and how they can have input; and keep getting things done, showing results. I'd say that list is actually in reverse order of importance.

Perhaps. I like the order I suggested because it emphasizes the fact that there's lots of work that's worth doing on OLPC's platform regardless of what OLPC thinks of the work and further, that OLPC is well-advised to encourage and enable you to perform that work because it deepens the collective pool of knowledge of OLPC's platform and because OLPC regularly changes its mind. --Michael Stone 02:13, 28 May 2008 (EDT)

Still, taking the first/least important item. I think that the MOST important improvement in the build process is to be more compartmental about things. If I want to do some work on area X, which may include adding dependency Y, I want to have to touch (branch) as few things as possible and (less crucial) install/configure as few things as possible to do everything I need including doing a whole build. There are arguments to be made for keeping things more monolithic (one step makes a branch, if you end up having to move up or down the stack later you have all that ready; but this does not encourage good modularization for current navigability and later separability) or for smaller modules (better design but more headache when branching - tools are key then). I think that "smaller modules" is the right answer, but this puts the focus having ways to manage dependencies between changes in different modules.216.106.175.189 08:02, 24 May 2008 (EDT)

I didn't really follow this paragraph. Can you please simplify it for me? Thanks. --Michael Stone 02:13, 28 May 2008 (EDT)