On 8/20/13 12:07 PM, Ajo Fod wrote: > My 2c worth. It seems like there is a general bottleneck. A lot of ideas > don't get used because there is a hurdle that people have to make change > that satisfy all code requirements like tests/reuse of blocks etc. This > makes for a larger than necessary hurdle for people to contribute. > > Looks like Gilles tried to solve this problem. One alternative is to place > alternative/new code in a nursery/experimental package parallel to the main > line of code. This nursery code wouldn't be subject to the deprecation step > or stability guarantees. The nursery packages should be better than the > main line of code or solve an unsolved problem demonstrated with > appropriate tests. > > That way, users will be aware of and can beInefit from the ability to solve > a problem in CM. This will also be "advertisement" for the needed work to > include the work in the main line of code.
I think we have agreed that either svn branches or git forks can address the "scratch space" issue. I have a comment on the general collaboration approach, though, which is just my HO. There are lots of different collaboration styles in OSS projects. One thing that is common to pretty much all of them though is that if your goal is to "get your patches in" you are actually much better off focusing first on learning how the community works and becoming a "net energy producer" within the community. Just tossing patches in and asking why they are not committed is net energy drain. Doing simple stuff like following the coding guidelines, taking time to understand the existing code, searching the archives for previous discussion, doing background research that helps the community get on the same page, you establish yourself as a *net source of energy.* That makes others more willing and interested in working with you. Then your patches get committed and you eventually get to commit them yourself :) I know we have made some bad design decisions. I know we will make more. We honestly vacillate between just focusing on getting algorithms soundly implemented and good API design. Pretty much all of our bad API decisions have been the result of us wanting to just get useful stuff implemented while trying to keep the API minimally stable. I know we are sometimes grouchy and argumentative and we have some really diverse views among the committers here. We need to work on the grouchiness, but the diversity is a strength. We honestly welcome better ideas; but I agree with Gilles that vague, generally negative commentary has zero value to us. Constructive criticism, good questions and patches are always welcome. We especially appreciate feedback based on practical applications (e.g. Ward's use cases) and advice/comments from those with expertise related to the algorithms that we are implementing. Phil > > Cheers, > -Ajo > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
