While I don't necessarily disagree with this guideline it doesn't seem that it belongs here. Until a project is accepted no formal relationship between the proposer and the ASF exists (right?), so this guideline cannot be enforced or even expected to be known to the proposing party. (It only seems to apply to the typically narrow window between the acceptance of a project and the code drop.)
I disagree that this guideline can not expected to be known by the proposing party. Would you not agree that there is some minimum amount of due diligence required to submit a proposal? For example, it's become standard that people use a certain general model or template to submit their proposals. (We are now trying to create an official template, but the last X submissions have largely followed the same unofficial pattern). I don't think it's unreasonable that we expect proposing parties to at least browse and read parts of the incubator web site prior to a submission. Our obligation, as the incubator, would be to 1) ensure that any official guidelines we develop are prominently and visibly displayed on the incubator web site, 2) promote community and cultural processes that reinforce these practices.
> 6. The Apache PRC SHALL affirmatively and publicly respond to any such > inaccurate publicity surrounding podlings. I'm not quite comfortable with the word inaccurate here. What exactly does it refer to? (Assuming it's bullet 5, there doesn't seem anything inaccurate about putting out a press release announcing the proposal of a project, ill-advised though it may be.)
Inaccurate may be an imprecise word. Perhaps we should s/inaccurate/unapproved of and factually incorrect. This also seems like a catch 22. Until a proposal has been accepted
there is no podling to speak of, so the proposer can do whatever they want (including put out a press release announcing it). And
Theoretically, a proposer could put out a press release announcing a podling before a proposal was submitted (and in fact, this has happened in the past). Practically speaking, we can't prevent this from happening. But if a proposer were to do this, the proposer would receive a highly negative response from the community. We want to prevent such things from happening - we want to increase the likelihood that any relationship between the ASF and its ecosystem will be fruitful from the very start. The purpose of these guidelines is that we are trying to codify informal policies and procedures that are already in place, and make these clear and concise to our community. The problem with informal policies and procedures is that there all of these unspoken expectations from members of the community about what *should* happen, but then newcomers to the community have no idea what these expectations are, and then understandably are confused/upset/etc when we punish them (either implicitly or explicitly) for violating these expectations. Speaking with PRC hat, Susan
