Hi Geertjan,
not quite sure how to read this ... what are you referring to as "new culture".
The existing project coming to the ASF? And this project should adopt the
tradition of the ASF.
Or that the ASF should adopt the culture and tradition of the project joining?
(Probably then meant more as: Allowing them to continue than the ASF to change)
I think projects coming to the ASF have to be educated prior to entering
incubation that
there will almost always be things we are expecting them to change when they
come to Apache
and that there's no discussion on if they have to follow them.
We have to make them understand that the ASF is more than a GIT repo, CI Server
and Mailing lists.
That the ASF has great things to provide (Legal Shield, Marketing, Infra, ...)
but that this only works
If you play along with some rules we have. Also should we explain WHY these
rules are there.
I would say it's sort of like emigrating to another country: You probably move
for some reasons.
But also probably the rules are a little different at the country you are
moving. There will be things
You will be allowed to do the same way you always did it, but there will be
things expected of you
to simply follow and not ignore, because you think otherwise.
We have to find a way to state the rules and what we expect before podlings
enter incubation.
Still we will have podlings that sort of remind me of small children simply not
willing to do something simple,
Just cause a parent told them to: "No, I will not say thank you".
Or converted to our world: "No, I will not add anything to any Notice", or "No,
I will not credit stuff I
obviously borrowed somewhere" ... but this way we can always refer to the rules
being clearly
communicated prior to entering incubation and not have to listen to complaints
all the time.
And for my point of view: If there are projects, that join the ASF, but don't
want to play according to the
Rules - we're off way better without them. At least I don't want to invest my
time (which is already
Spread out pretty thin with all the things I do for the ASF) to deal with
rebellious podlings.
Chris
Perhaps creating a training session as part of the training podling
Am 13.06.19, 22:29 schrieb "Geertjan Wielenga" <geert...@apache.org>:
Speaking on behalf of myself only, though note I am PMC chair of NetBeans,
which went through a protracted (nice way of saying ‘complex’) incubation
because of its size (‘very large’) and history (20+ years) — the key to any
new culture is to adopt its traditions and to fight them as little as
possible. And one can’t really understand the culture until one is in it.
It’s hard to really prepare — other than to admire projects like Maven or
TomEE and to want and aim to be like them, regardless of the contortions
required to get there.
Gj
On Thu, 13 Jun 2019 at 21:10, Dave Fisher <dave2w...@comcast.net> wrote:
> Hi -
>
> Here are some thoughts I have to improving Incubation. These are not
> really new, but I think we should discuss where and how best to apply
these.
>
> (1) Champions need to very clear that the ASF expects Community decisions
> not BDFLs. Burnout is one factor to highlight why community is important.
> Vendor independence is important and part of why BDFLs don’t fly. In the
> last few years we have deemphasized the role of Champion and I think we
> need to list out some of the duties a Champion has to both the prospective
> podling community and the Incubator.
>
> (2) We should help existing communities plan their entry into Incubation
> with their proposals. Currently TVM is moving their community over before
> repositories. That might be a better approach for many communities as it
> will assure that (a) the existing community keeps its current velocity and
> (b) they are making community decisions on list before actual development
> is moved over.
>
> (3) Having a lower impedance to release and code changes would really
> help. We are already having this discussion. A very radical idea might be
> to move a lot of the License, Notice and Dependency work away from the
> Release Vote and instead do periodic and potentially automated audits of
> repositories. This would follow the REVIEW suggestion, but make it more
> automated and based on tooling.
>
> (4) Relinquishing control of admin rights on GitHub repos is an impedance.
> I understand why this is done from an Apache Infrastructure perspective,
> but it is a surprise to podling communities. Making sure that a new
podling
> knows fully what to expect before transferring repos would really help
> manage expectations.
>
> (5) Failure to incubate is not failure. Currently 63 podlings have retired
> and there are two or three additional retirements soon. 4 or 5 podlings
> moved on or back to where they were. The why of retirement could be
> analyzed, but it would need to look into mailing list archives because the
> information in podlings.xml is not always clear and is sometimes more
> diplomatic than the reality.
>
> See https://projects.apache.org for an intriguing chart.
>
> Regards,
> Dave
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>
