On 10/6/06, Niclas Hedhman <[EMAIL PROTECTED]> wrote:
If the Proposer controls the Proposal (and not stick it on a freely editable Wiki), then isn't it very straight forward?
+1, although I think a Wiki still *should* work if the established etiquette was not to make edits to someone else's proposal
You feel excluded (I have); Convince the Proposor that you belong.
+1
You feel "piling on" is happening; Ask the Proposer to qualify the selection criteria, and have a dialog if you find it "inappropriate".
+1, and the Champion should be the first one to bring up this topic with the proposed initial committers, before the proposal even shows up at Apache.
I mean, who cares if "Company X" starts a podling in ASF Incubator with 400 employees getting commit access to that project?
+1, I think it is a mistake to impose an artificial limit to the number of people who can be initial committers from the same company if each one of them is going to be spending a significant amount of time working on the project.
If we change the wording in Graduation Criteria to include "maximum 30% of committers from the same company", then that excessive initial PPMC on the Proposal quickly becomes a handicap.
I agree with the sentiment here, but we've been through the 50% rule before and found it to have flaws. There have been podlings that most Incubator PMC members were quite happy with by the time the graduation vote came around, but they consisted of >50% from the same employer. We specifically dropped the 50% requirement about 2.5 years ago when we saw that a podling was operating openly, transparently, and based on merit; and, they had added a couple committers to further diversify the group, but were having trouble finding more contributors with consistent and valuable contributions to bring in as a committer. They also didn't want to drastically drop the 'merit bar' for committers just to meet some imposed percentage so they could graduate (many ways to 'game the system' here). What I believe we've found works best over the years is to consider the entire behavior of the project over its incubation and raise questions about any trends pushing it in the wrong direction. We also should consider any actual or perceived employer domination that is either biasing project decisions or intimidating others from getting involved. I wish we could just have an objective list of numerical requirements, but I think it has to come down to the judgement of the Incubator PMC members. (not to say that I thought Niclas was advocating for a particular numerical requirement right now -- I just wanted to agree with his idea that employer domination can be considered at graduation, but caution the use of hard numbers) Cliff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]