On 2/10/14, 3:05 PM, Joseph Schaefer wrote: > Frankly the notion that there is empirical evidence that > the standard Apache process is “too slow and buggy” is a straw man. > I have over a decade of personal anecdotal evidence watching > Apache projects self-improve and serve the needs of their > communities rather well. If anything, I’d say many projects > go too fast already, especially when they are doing a new > major release. A full week’s soak out on the dev list usually > produces fewer duds in those circumstances. > > I don’t deny that there is literature that says faster releases > are ‘better’, but that observation lacks a base point relative > to Apache processes. Clearly we can all agree that there is > a notion of going “too fast”, going “too slow”, and a desire amongst > some people to “go faster”, but those are entirely subjective > and seemingly lack any assessment of the consequences of theses > choices on healthy group dynamics. After all, Apache projects > are all in the recruitment business, and I don’t see how speed > for the sake of speed leads to more activity from newcomers to > the process. All I see are comments like how great it is that > we are giving users fast turnaround on their bugs, but no mention > of how we are capturing those users attention and converting their > self-interest into project development.
That is an interesting question that would be tricky but possible to look at empirically - how does release frequency correlate with user engagement? The tricky bit is how to measure user engagement. Not just list traffic / JIRAs, but sustained contribution from users of the software. In projects dominated by paid developers it might be hard to identify and track users coming into the community. I wonder if anyone has tried to do this. Phil > > > > On Feb 10, 2014, at 5:47 PM, jan i <j...@apache.org> wrote: > >> On 10 February 2014 23:13, Marvin Humphrey <mar...@rectangular.com> wrote: >> >>> On Mon, Feb 10, 2014 at 1:54 PM, jan i <j...@apache.org> wrote: >>> >>>> I strongly believe we (ASF) shall do whatever we can to make sure our >>>> releases are as stable as possible ! >>> Those who advocate scheduled releases and a fast cadence believe that they >>> are >>> doing exactly that. In fact, the argument goes that bunching up large >>> amounts >>> of changes in each release makes for lower quality. >>> >>> Who's right, you or them? Are you so sure of your conclusion that you >>> believe >>> communities which want to follow these practices must be excluded from the >>> ASF >>> because you believe their software will inevitably be low quality? >>> >> I just made personal observations from my personal experience. I am not the >> one to judge who is right or wrong. And please remark I did not talk about >> excluding projects, that would be very wrong ! >> >> I have worked mainly with international projects with participants from >> many continents (like many of our projects), and maybe that fact is the >> root cause of the problems I have experienced. Having to cope with >> china/europe/US within a 24 hour frame, often lead to the problems I >> described, and I can only assume it must be a lot harder with volunteers. >> >> I simply tried to suggest a middleway that might be (or might not be) >> acceptable to broader group. >> >> >>> This isn't new, or experimental. It's a major movement in software >>> development, years old, with many popular, successful projects on board. >>> >>> Marvin Humphrey >
