From below: "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."
....
I will be submitting a proposal soon, and have followed the form of the
most recent submissions. Will
this discussion have material impact on the form of a submission in the
next few weeks?
Carl.
sophitia que wrote:
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org