incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <>
Subject Re: Incubation Pain Points
Date Wed, 19 Jun 2019 16:57:50 GMT
Hi -

In retrospect this phrase:

"Better documentation, relaxing ASF policy or putting off stuff until graduation might improve
things, but probably(sic) doesn't solve the core issue.”

I wonder if we agree on the Core issue? To me the core issue is that starting in the Incubator
is hard, intimidating, and presents a steep initial learning curve. But when you say putting
stuff off until graduation that is a different issue.

Let’s draw some ASCII graphs.

Which picture is best? (Horizontal is time and vertical closeness to graduation.)

(A) Current view:


(B) Slow and easy:


(C) Wait until the last minute


I think that prolongs want to be in a (B) pattern. Ones that carefully move through the Incubator
have a (B) type experience unless they are already quite experienced in which case they are
an (A) and need little guidance from the whole IPMC.

An important point is that these graphs of progress towards graduation are on at least three

(1) Apache Release (and Distribution) Policy
(2) Apache Governance
(3) Community Growth

Perhaps a Core issue includes an over focus on (1), when (3) via (2) is IMO more important.

Maybe we need to reorder our curriculum?


> On Jun 19, 2019, at 8:39 AM, Dave Fisher <> wrote:
> Hi Justin,
> You are certainly correct about this. I’ve been learning to cook the last few years
and have a cupboard full of recipes to follow.
> I made a directory in the incubator git for us all to share our tools and recipes in
the hopes that they are useful.
> I’ll add a few of my simple scripts later.
> Regards,
> Dave
>> On Jun 19, 2019, at 12:31 AM, Justin Mclean <> wrote:
>> Hi,
>> The IPMC does share its experiences and tools it uses, and it's up to podlings (with
their mentors help) to find out how best to use them for their releases. There's unlikely
to be a single solution that fits all podlings without a lot more work on the podling side,
which would probably cause some loud objections.
>> Tooling/automation can't catch all issues with the LICENSE/NOTICE and some other
issues. Plain text is hard to parse and understand by computers, it often contains errors
and is unclear or imprecise. Even if we moved to SPDX, (or something similar that is easier
for code to parse), it would be much more work for podlings than what we currently do.
>> I know that being a bunch of people who like coding, we tend to think that a solution
to an issue can be solved by more code. Most (more than 1/2) of the severe issues caught by
IPMC voting on releases would be very unlikely to be caught by tooling. (For examples see
recent votes).
>> Release checking tooling and automating that are useful tools, and will undoubtedly
catch some minor and some severe issues. I'm all for using them, but the output of tools like
Rat (and others) require tuning and interpretation, and currently, I don't think that on their
own can replace human eyeballs or catch all issues in a release. These tools do have some
room for improvement, but tooling is complementary to manual inspection and only enhances
it, it doesn’t replace it.
>> People (adult learners) also learn best by doing, offloading that to automation means
that a podling may not learn the essential values behind why a release needs to be the way
it is or may not even care what those values are. Is this what we want?
>> While some podlings may have an issue with the first release, past this the majority
of podlings don't have any major issues. Around 80% of releases pass the IPMC vote, ignoring
the first couple of releases that means about  90-95% of all releases pass. So what we are
talking about are the exceptions to what commonly occurs, and I think the problem needs to
be framed in that context. The main areas I believe where this can be improved are mentor
engagement, mentor education and looking into how those values, skills and knowledge are transferred
to the podling. Better documentation, relaxing ASF policy or putting off stuff until graduation
might improve things, but propobably doesn't solve the core issue.
>> When you ask an expert baker how to make bread, they say "just add yeast and flour
and water, kneed, let rise and bake", they may not even give amounts or times. They know from
experience what to do, and may not even be conscious of that knowledge or of the reasons why
they do things in a certain way. They will change the ingredient amounts based on the current
conditions, how humid it is, the type of flour, how it feels when kneading etc. Again, they
may not be conscious of doing it, let along be able to communicate that information clearly
to others. There are of course exceptions to this, but in general, they seem to think that
it's intuitive and easy to do, and may be puzzled when other people don't get it. That's why
experts sometimes don't make the best teachers or the best people to pass on their experience,
skills and knowledge.
>> Adult learners (in general) want to know how to do something just before they do
it, they tend not to want to know the theory behind it, but want simple, practical guidance.
They also learn in different ways; having it written down is a start but not enough. The material
with the best learning outcomes engages people in multiple sensory ways to impart the skills
and knowledge required. The best way of learning how to do something is to try it out.
>> So back to making bread, you can give someone a step by recipe to work with and someone
will be able to make bread. Their first try may not work, but they should get better with
each try, especially with help. It may not be as good as made by the professional baker, but
it is likely to be good enough to eat.
>> If you want to learn how to make releases, I would suggest you read about the Apache
Way, read ASF policies, go listen to a couple of talks on this from previous ApacheCons, look
at previous release votes here on this list, and ask your mentors (or IPMC) for advice, but
most importantly try doing it for yourself. Once you worked out the best way to do it, then
start automating that.
>> Thanks,
>> Justin
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message