Alex, Jim, Bertrand, This discussion is re-inventing a discussion that has been had before. At one time, the incubator tried to present principles to incoming podling (albeit not in a very well documented fashion). The reaction was that podlings strongly wanted specifics, not general principles. The idea of "no category x" worked, but things like "no downstream constraints" were a bit too vague. And some mostly kind of sort of accepted Apache ideas like votes should mostly be used to record consensus rather than make decisions are definitely too vague.
OK. So we learned that lesson. And the maturity model was created. And documentation was done. One very clear sub-lesson is the unwritten rules really don't work when there are a large number of new people. Peoples' understanding changes or varies even when there is apparent consensus. Unwritten rules are also just not visible enough and can't be passed from one newbie to another. And here we are. Folks are now saying that we need to be a lot looser. That there is a lot of leeway in how projects interpret the traditions we have. That we should just specify abstract invariants. A lot of that involves some good ideas. But we need to not just circle back to the exact same place we started. We can damp the pendulum a bit by the following going to a middle ground: 1) *Add* the abstract principles (aka invariants) to an introduction to our documentation. 2) Use the maturity model. But add a statement that a project could negotiate an alternative maturity model during incubation as long as the IPMC agrees and it meets the invariants. 3) allow some non-conforming podling releases with special approvals. On Tue, Jun 18, 2019 at 9:32 AM Alex Harui <aha...@adobe.com.invalid> wrote: > > > On 6/18/19, 5:03 AM, "Jim Jagielski" <j...@jagunet.com> wrote: > > > > > On Jun 18, 2019, at 7:42 AM, Bertrand Delacretaz < > bdelacre...@codeconsult.ch> wrote: > > > > On Tue, Jun 18, 2019 at 1:18 PM Jim Jagielski <j...@jagunet.com> > wrote: > >> ...prepping the existing community regarding what "moving to the > ASF means" is the job of the Champion, no?... > > > > I agree but it has to be based on written docs, not oral tradition as > > that does not scale. > > > > Of course... but lack of it being on written docs does not make it > invalid nor not policy. > > Just trying to follow these threads, it isn't clear there is agreement, > even among the "old-timers", as to what the invariants really are whether > written or oral. > > For example, I'm a bit surprised that none of the old-timers disagreed > that there is an Apache Culture and that incubation is about assimilating > into that culture. I thought I read many times on various ASF lists that > the ASF is comprised of many projects each with their own culture. And > that the only common ground is a "Way" not a "Culture". But then various > folks try to define the "Apache Way" and other folks disagree with their > definition. > > At least in the US, there are many places where the residents have formed > or retained their own culture. Folks immigrating to the US are not > required to assimilate into any particular aspect of US culture. They are > only asked to obey certain laws. And even then, the strictness of law > enforcement is somewhat influenced by the local culture and context. > > What really are the invariants at the ASF that require strict inflexible > immediate enforcement? I think there are really only a relatively small > number of them: > > 1) No closed source in a release > 2) No CatX in a release > 3) No corporation owns decision making > 4) Majority vote on releases > 5) No advertising the general availability of non-releases. > 6) A protocol for handling security issues. > 7) ASF does not pay developers > 8) Don't violate US Non-Profit rules > > A podling could be granted more flexibility around #2 and #5 with the > additional requirement of DISCLAIMER and -incubating labels. > > Could everything else really be seen as goals for a community? Then it > would be "Community over Code and Policy except these 8 things". > > My 2 cents, > -Alex > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org >
