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 dimensions:
(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?
Regards,
Dave
> On Jun 19, 2019, at 8:39 AM, Dave Fisher <dave2w...@comcast.net> 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.
>
> https://github.com/apache/incubator/tree/master/tools
>
> I’ll add a few of my simple scripts later.
>
> Regards,
> Dave
>
>> On Jun 19, 2019, at 12:31 AM, Justin Mclean <jus...@classsoftware.com> 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: 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
