In general I'd prefer less discussion rather than more, applying the following rules:
1. deviations that get us closer to an established goal do not require discussion 2. ditto for refactors / improvements of existing functionality 3. new core features where there may be disagreement as to the requirements require some discussion beforehand. 4. non-core features should not require discussion unless they are found be a nuisance or until it is determined that they are in fact core features. Examples: 1. e.g. my tweaks to deployment 2. e.g. go through BpelServerImpl and fix the multi-threaded concurrency issues 3. e.g. versioning, content api, business transactions, etc... 4. e.g. implement a debugging facility, support additional query language, etc.. All these are subjective of course. If something more rigid is called for then we might consider establishing ownership responsibilities for certain areas of the project so that we don't have to get bogged down in endless discussions. Of course there would always be recourse to democracy: if for example there is a big disagreement that cannot be worked out between someone working on the engine, and the API owner, then this nuclear option is always available. -maciej On Tue, 2006-08-15 at 10:37 -0600, Lance Waterman wrote: > Maciej, > > I am trying to understand expectations around how the ODE project > plans to work. Based on past exchanges you made the following comment: > > >>I think the versioning changes will require an understanding of how > the > >>feature would be implemented -- a design reveiew. As for the scratch > vs > >>patch, scratch is called for when multiple developers are going to > be > >>involved in developing a feature. > > and Alex made the following comment: > > >>An idea: you could also create a temporary branch to make it easier > to > >>share, collaborate and merge/synchronize the code if you think the > scope > >>warrants it. > > > Now I think I hear you saying that the interface is not stable and > folks should not be surprised if it should change ( i.e. adding > versioning ) without notification/discussion and at some future point > in time we may decide to lock it down. > > I find the following comment subjective: > > >>but on the whole I feel > >>that the changes I made were only getting us closer to the intent of > the > >>group WRT deployment. > > So I am struggling with expectations around design/interface changes. > I personally would like to see discussion around changes to the public > interface before being checked into the trunk. For example; I would > like more information around some questions I had on methods added to > the BpelServer interface. > > However, if there is consensus that the group would rather work within > a more fluid environment that is fine with me. In this more fluid > environment I don't think we can fault folks for their subjective view > on interface/implementation changes and the only thing we can do is > ask questions and make suggestions after the fact. > > Again, I can work in either environment but I would really like to > hear from folks and come up with a consensus on how they see the > development process working. > > Thanks, > > Lance >
