You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Dave Fisher <da...@comcast.net> on 2019/06/13 19:10:13 UTC
Incubation Pain Points
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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubation Pain Points
Posted by Dave Fisher <da...@comcast.net>.
> On Jun 18, 2019, at 4:42 AM, Bertrand Delacretaz <bd...@codeconsult.ch> wrote:
>
> On Tue, Jun 18, 2019 at 1:18 PM Jim Jagielski <ji...@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.
>
> http://incubator.apache.org/cookbook/#does_our_project_fit_the_apache_incubator
> does address this at least partly, IMO.
There has not been much traction on the cookbook changes that you started.
(1) I think a refocus on the cookbook would be helpful.
As part of the Cookbook update we should make sure of the main points of the Apache Way / Culture / minimums are documented. Alex’s list else thread is as good a start as any.
(2) Thanks for linking to the Board thread from February. There is some support there for allowing Podling Releases to entirely PPMC based assuming there is enough Mentor engagement.
Advantages included:
- Keeps Releases in the Community. Provided they meet minimums.
- Avoids the need for “heroics” from those who review 100s of releases.
Disadvantages might include:
- Initial Podling Releases cannot be wholly under the "legal shield" depending on how that is interpreted.
- Some think that Release issues won’t be handled until just before graduation.
I propose that the IPMC comfirms an updated policy that we expect that Podling’s Apache Releases initially conform to a minimum that includes a DISCLAIMER that is invariant aside from the podling name, and fits Apache Distribution Policy plus including “-incubator” or “-incubating” in the filenames of all artifacts except the KEYS.
Before graduation each of the podling’s released products must be confirmed by their Mentors to conform to Apache Release Policy. If there are not enough active Mentors then the podling should (a) request additional mentors and/or (b) request a review on general@. Such a review should not be during the release of a version of the product. If the Mentors have any concerns or questions then they can request the review from general@ themselves.
(3) Does anyone have a sense about how many retired podlings where failure to incubate was due to release problems? And, if so can that be differentiated from other community issues?
(4) Convenience Binary releases need careful discussion in another thread since these are ever evolving as new packaging and container technology is under continual development. I think that this is another thread that should be pursued after we settle on Podling Release Policy.
Regards,
Dave
>
> -Bertrand
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubation Pain Points
Posted by Dave Fisher <da...@comcast.net>.
Apologies for replying twice in a row to the thread.
> On Jun 18, 2019, at 10:32 AM, Ted Dunning <te...@gmail.com> wrote:
>
> 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.
We can use the cookbook that Bertrand started.
>
> 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.
I was once a doubter, but I’ve come around. +1
>
> 3) allow some non-conforming podling releases with special approvals.
See my other email just posted in this thread. I don’t think we need special approvals if we have Mentors guiding the podling towards conformance which we all agree is the final goal. If the podling has issues that need exceptions to the Release Policy then the Mentors should guide them to legal-discuss@ and note any decisions.
Regards,
Dave
>
>
>
> On Tue, Jun 18, 2019 at 9:32 AM Alex Harui <ah...@adobe.com.invalid> wrote:
>
>>
>>
>> On 6/18/19, 5:03 AM, "Jim Jagielski" <ji...@jaguNET.com> wrote:
>>
>>
>>
>>> On Jun 18, 2019, at 7:42 AM, Bertrand Delacretaz <
>> bdelacretaz@codeconsult.ch> wrote:
>>>
>>> On Tue, Jun 18, 2019 at 1:18 PM Jim Jagielski <ji...@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-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubation Pain Points
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Jun 19, 2019 at 1:02 PM Alex Harui <ah...@adobe.com.invalid> wrote:
>...
> To close with Justin's bread analogy: A bread maker that just says "just
> add yeast and flour and water, kneed, let rise and bake" and then makes you
> toss out the results and start over is not going to attract nearly as many
> students as the bread making expert who can more clearly provide
> instructions in a friendly way, helps you catch your mistakes before you go
> too far down the road, and doesn't make you start over except in a few
> extreme cases. For sure, if you sign up to be a bread making apprentice at
> the most prestigious bakery, then you can expect less leniency and stricter
> standards. It is up to the ASF to decide if they want the reputation of
> being that picky or not. I hope not.
>
And an even better bread maker allows you to make pies for a year (cuz why
not?), knowing you'll eventually be a great bread maker under their
tutelage.
Cheers,
-g
Re: Incubation Pain Points
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I know this isn't the latest posts on this thread, but this is the post that best suits what I want to say.
Almost all of my posts recently have been about trying to determine if all policies must be attached to the same pendulum. I think I'm seeing from Ted, Roy (in the past), and Hen that some policies are more important than others.
IMO, each policy could be graded under 4 categories:
1) inflexibility/ambiguity - are there different ways to interpret/implement the policy
2) effort to prevent non-compliance
3) cost/effort to fix non-compliance
4) cost/effort of non-compliance
I'm going to assume that the cost of canceling a release candidate is significant, not just in person-time, but momentum, and time due to restarting the 72-hour vote clock.
When a policy has ambiguity, or requires effort to prevent non-compliance, including understanding the policy and how to apply it, and it can result in a high cost effort to fix, you have the perfect storm, and so you'll receive feedback to try to eliminate ambiguity or reduce effort to prevent, or make the policy easier to understand and apply (or improve tools to find non-compliance). But if it turns out you can simply reduce the cost to fix by not having that policy be a release breaker, then I don't think you'll get as much feedback asking for the policy or tools to be more specific.
I think I see consensus that the only truly important release policies are around:
1) Legal right to distribute. IMO, this is inflexible, and not ambiguous. The policy is easy to understand: you either have documentation that says you can distribute each line of code or you don't. There is effort required to check each line of code, but the cost of non-compliance is significant.
2) No usage restrictions. IMO, this is inflexible for TLPs. It is ambiguous only in the sense that new situations could come up that haven't been covered before, but I think we could just list the most common things that cause usage restrictions and that would help folks get a sense of what this is all about.
The only wiggle room in these two may be in the quality of the documents. It should be ok to ship something where there is general consensus that there is a right to distribute even though the supporting documents aren't perfect. For example, a file is not listed in an SGA but doesn't really contain anything important, or the words chosen to document a re-licensing from GPL to MIT could be better, or the license was changed from GPL to MIT in every file but one due to a clerical error.
Everything else related to releases could be fixed later, significantly reducing the cost to fix.
And then the only other thing I would suggest beyond that is trying to get advisors to preface advice with "this is how I would (or have) done it", especially for the more ambiguous or hard-to-understand policies. And that, I think would stop the pendulum from swinging.
For Podlings, the cost of fixing a usage restriction issue can be significant if they have been relying on, say, a GPL dependency before coming to the ASF. I hope someone with authority (VP Legal, Board) finally decides that the DISCLAIMER is enough to let podlings have the time to replace that dependency or make it optional.
IMO, the Maturity Model contains a lot of things that are ambiguous because there are multiple ways to implement it. I think that's totally fine: I thought the ASF was ok with diversity in how projects execute. And so the introductory materials about the Incubator should state that you may get differing opinions and that is fine. Maybe the MM should indicate which ones are not flexible (where you shouldn't be getting different advice from different people on how to execute). I think it would be LC10-40, RE20&30.
To close with Justin's bread analogy: A bread maker that just says "just add yeast and flour and water, kneed, let rise and bake" and then makes you toss out the results and start over is not going to attract nearly as many students as the bread making expert who can more clearly provide instructions in a friendly way, helps you catch your mistakes before you go too far down the road, and doesn't make you start over except in a few extreme cases. For sure, if you sign up to be a bread making apprentice at the most prestigious bakery, then you can expect less leniency and stricter standards. It is up to the ASF to decide if they want the reputation of being that picky or not. I hope not.
My 2 cents,
-Alex
On 6/18/19, 10:33 AM, "Ted Dunning" <te...@gmail.com> wrote:
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 <ah...@adobe.com.invalid> wrote:
>
>
> On 6/18/19, 5:03 AM, "Jim Jagielski" <ji...@jaguNET.com> wrote:
>
>
>
> > On Jun 18, 2019, at 7:42 AM, Bertrand Delacretaz <
> bdelacretaz@codeconsult.ch> wrote:
> >
> > On Tue, Jun 18, 2019 at 1:18 PM Jim Jagielski <ji...@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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubation Pain Points
Posted by Ted Dunning <te...@gmail.com>.
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 <ah...@adobe.com.invalid> wrote:
>
>
> On 6/18/19, 5:03 AM, "Jim Jagielski" <ji...@jaguNET.com> wrote:
>
>
>
> > On Jun 18, 2019, at 7:42 AM, Bertrand Delacretaz <
> bdelacretaz@codeconsult.ch> wrote:
> >
> > On Tue, Jun 18, 2019 at 1:18 PM Jim Jagielski <ji...@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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Re: Incubation Pain Points
Posted by Alex Harui <ah...@adobe.com.INVALID>.
On 6/18/19, 5:03 AM, "Jim Jagielski" <ji...@jaguNET.com> wrote:
> On Jun 18, 2019, at 7:42 AM, Bertrand Delacretaz <bd...@codeconsult.ch> wrote:
>
> On Tue, Jun 18, 2019 at 1:18 PM Jim Jagielski <ji...@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubation Pain Points
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Jun 18, 2019, at 7:42 AM, Bertrand Delacretaz <bd...@codeconsult.ch> wrote:
>
> On Tue, Jun 18, 2019 at 1:18 PM Jim Jagielski <ji...@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.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubation Pain Points
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Tue, Jun 18, 2019 at 1:18 PM Jim Jagielski <ji...@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.
http://incubator.apache.org/cookbook/#does_our_project_fit_the_apache_incubator
does address this at least partly, IMO.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubation Pain Points
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Jun 17, 2019, at 1:25 PM, Dave Fisher <da...@comcast.net> wrote:
>
> Hi Roman,
>
> All very true. What the Incubator could do better is to let people know the key values of The Apache Way that will impact any existing community if they come to the ASF through the Incubator. While it will be a community that comes (or doesn’t), it will more likely be a vendor than a community that decides to come to Apache. That will more likely be for the permissive licensing than for community over code.
Certainly prepping the existing community regarding what "moving to the ASF means" is the job of the Champion, no?
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubation Pain Points
Posted by Geertjan Wielenga <ge...@apache.org>.
I think a big and simple thing to consider is that the difference between
success/failure in migrating to Apache TLP is one of attitude -- i.e., the
very same things that the Zipkin community considered to be immensely
frustrating were considered to be immensely frustrating to the NetBeans
community too. However, in the case of the NetBeans community we (1) didn't
have the pre-history of going it alone that Zipkin has, i.e., for Zipkin
there was always the possibility of going back to their independent status
before Apache, while for NetBeans the prior state was Oracle and NetBeans
couldn't go back, it simply needed a governance model and so if it wasn't
going to be Apache it would have been something else, which would have been
frustrating to get into as well, so we just simply persevered until we
adopted everything and accepted everything and (2) Zipkin seems to be less
cohesive than NetBeans and less interested in being cohesive, i.e.,
concerned about laying down things for subgroups that might be averse to
that, while NetBeans is a pretty holistic organism working towards very
similar end goals. So, it's as much the nature of the specifics of a
community or project as it is about the specifics of Apache, the Apache
Way, the Incubator, etc.
Gj
On Mon, Jun 17, 2019 at 7:26 PM Dave Fisher <da...@comcast.net> wrote:
> Hi Roman,
>
> All very true. What the Incubator could do better is to let people know
> the key values of The Apache Way that will impact any existing community if
> they come to the ASF through the Incubator. While it will be a community
> that comes (or doesn’t), it will more likely be a vendor than a community
> that decides to come to Apache. That will more likely be for the permissive
> licensing than for community over code.
>
> (1) The careful Apache Licensing and Release process that is not fully
> automated might be a surprise. If a project relies on frequent and quick
> releases then there will be a cultural issue as the project adapts. This
> needs to be fully considered. Projects need to discuss a more careful and
> deliberate transition between existing process and the ASF. Moving over
> repositories immediately might not be best.
>
> Yes, the IPMC can help lower the impedance for a release. I think rather
> than parallel releases we should allow projects whose communities need
> faster releases to be slower about moving repositories to Apache.
>
> (2) Community over code means global asynchronous communications with
> decisions in public based on Consensus. Consensus is often simple (Lazy),
> but is sometimes very difficult. This is the opposite from a “king” or BFDL
> (aka Linux Kernel, etc.) and it is not driven from within a “Vendor” team
> (at least not in the end.) The very foundation of the Apache Group was to
> bring back an abandoned project. An Apache project with a functioning PMC
> replaces committers from the community and supports the community of users.
> In many PMCs the original developers are long gone and some are likely in a
> fourth or fifth generation of committers.
>
> I think that the IPMC should recommend that mailing list communications be
> fully established prior to moving repositories. Rather than having the
> quickest most active developer take charge immediately we get Consensus
> from all the Initial Committers about it being time to move a repository.
> The choice of Transferring vs. Cloning needs to be clearly made.
>
> Surprises with repositories include giving up some admin rights and
> plugins in GitHub due to Apache’s management of 100s of repositories (close
> to 1000?) This will impact a project’s pipelines in unexpected ways.
>
> (3) Coming to Apache does mean there is a unique view on Foundation
> available resources. If a project wishes to Incubate with a number of extra
> resources then careful planning and possible exceptions to policies will
> need to be negotiated.
>
> I could go on, but I think we need to identify for prospective podlings
> what the main cultural points are so that they can know if they will have
> trouble.
>
> I think that the podling proposal template should be updated to be less
> verbose and more about the podling community clearly understanding what its
> going to happen and identifying what support the community will need.
>
> Regards,
> Dave
>
> > On Jun 17, 2019, at 9:02 AM, Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
> >
> > On Mon, Jun 17, 2019 at 8:51 AM Geertjan Wielenga <ge...@apache.org>
> wrote:
> >>
> >> It’s not really totally OK. People leaving back to their old place
> feeling
> >> unhappy and frustrated, how is that totally OK?
> >
> > I'll stick with Christofer's analogy -- if you come to a new country
> > thinking that
> > the roads are paved with gold -- all you're going to get is
> > frustration and unhappiness.
> > Not a single place is a paradise on earth.
> >
> > If, however, you come to the new country with the intent to learn and
> > see if this
> > place can *gradually* become your new home -- now you're talking.
> >
> > Obviously, this doesn't apply to refugees (I guess in our world it
> > would be corporate
> > refugees) but it applies extremely well to everyone else.
> >
> >> How positive is that departing community going to be about Apache? Is
> that really totally OK?
> >
> > I'm not sure if you fully realize this, but Apache is a TERRIBLE place
> > for a whole
> > bunch of communities (I could totally see this being misquoted -- but
> > I'm doing it on purpose).
> >
> > ASF is a HORRIBLE place to run Linux Kernel community. ASF is a
> > HORRIBLE place to
> > run any of the corporate-centric ASF communities, the list goes on.
> >
> > What we should aspire to is that, on balance, we're an excellent place
> > for the kinds of
> > communities that have an affinity to our governance model (and
> > license) but that's
> > about it.
> >
> >> I think it’s a sign that there was something wrong in the pre-incubation
> >> discussions, certainly some misconceptions. Sure, it’s not the end of
> the
> >> world to go back to the old place, but certainly not the ideal either.
> >
> > There's as much wrong about pre-incubation as it is with trying to guess
> whether
> > you'd feel at home in a country by looking at travel shows on TV.
> >
> > Thanks,
> > Roman.
> >
> >
> >> On Mon, 17 Jun 2019 at 17:36, Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
> >>
> >>> On Mon, Jun 17, 2019 at 1:24 AM Christofer Dutz
> >>> <ch...@c-ware.de> wrote:
> >>>>
> >>>> 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.
> >>>
> >>> This! Also, I think we should stop being so uptight about communities
> >>> trying incubation
> >>> and deciding that ASF is not for them. It is a two-ways street when it
> >>> comes to education.
> >>>
> >>>> 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.
> >>>
> >>> And sometimes you'd return back to your old place after all -- and
> >>> that's totally OK.
> >>>
> >>> Thanks,
> >>> Roman.
> >>>
> >>>> 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" <geertjan@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 <da...@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-unsubscribe@incubator.apache.org
> >>>>> For additional commands, e-mail: general-help@incubator.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >>> For additional commands, e-mail: general-help@incubator.apache.org
> >>>
> >>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Incubation Pain Points
Posted by Dave Fisher <da...@comcast.net>.
Hi Roman,
All very true. What the Incubator could do better is to let people know the key values of The Apache Way that will impact any existing community if they come to the ASF through the Incubator. While it will be a community that comes (or doesn’t), it will more likely be a vendor than a community that decides to come to Apache. That will more likely be for the permissive licensing than for community over code.
(1) The careful Apache Licensing and Release process that is not fully automated might be a surprise. If a project relies on frequent and quick releases then there will be a cultural issue as the project adapts. This needs to be fully considered. Projects need to discuss a more careful and deliberate transition between existing process and the ASF. Moving over repositories immediately might not be best.
Yes, the IPMC can help lower the impedance for a release. I think rather than parallel releases we should allow projects whose communities need faster releases to be slower about moving repositories to Apache.
(2) Community over code means global asynchronous communications with decisions in public based on Consensus. Consensus is often simple (Lazy), but is sometimes very difficult. This is the opposite from a “king” or BFDL (aka Linux Kernel, etc.) and it is not driven from within a “Vendor” team (at least not in the end.) The very foundation of the Apache Group was to bring back an abandoned project. An Apache project with a functioning PMC replaces committers from the community and supports the community of users. In many PMCs the original developers are long gone and some are likely in a fourth or fifth generation of committers.
I think that the IPMC should recommend that mailing list communications be fully established prior to moving repositories. Rather than having the quickest most active developer take charge immediately we get Consensus from all the Initial Committers about it being time to move a repository. The choice of Transferring vs. Cloning needs to be clearly made.
Surprises with repositories include giving up some admin rights and plugins in GitHub due to Apache’s management of 100s of repositories (close to 1000?) This will impact a project’s pipelines in unexpected ways.
(3) Coming to Apache does mean there is a unique view on Foundation available resources. If a project wishes to Incubate with a number of extra resources then careful planning and possible exceptions to policies will need to be negotiated.
I could go on, but I think we need to identify for prospective podlings what the main cultural points are so that they can know if they will have trouble.
I think that the podling proposal template should be updated to be less verbose and more about the podling community clearly understanding what its going to happen and identifying what support the community will need.
Regards,
Dave
> On Jun 17, 2019, at 9:02 AM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>
> On Mon, Jun 17, 2019 at 8:51 AM Geertjan Wielenga <ge...@apache.org> wrote:
>>
>> It’s not really totally OK. People leaving back to their old place feeling
>> unhappy and frustrated, how is that totally OK?
>
> I'll stick with Christofer's analogy -- if you come to a new country
> thinking that
> the roads are paved with gold -- all you're going to get is
> frustration and unhappiness.
> Not a single place is a paradise on earth.
>
> If, however, you come to the new country with the intent to learn and
> see if this
> place can *gradually* become your new home -- now you're talking.
>
> Obviously, this doesn't apply to refugees (I guess in our world it
> would be corporate
> refugees) but it applies extremely well to everyone else.
>
>> How positive is that departing community going to be about Apache? Is that really totally OK?
>
> I'm not sure if you fully realize this, but Apache is a TERRIBLE place
> for a whole
> bunch of communities (I could totally see this being misquoted -- but
> I'm doing it on purpose).
>
> ASF is a HORRIBLE place to run Linux Kernel community. ASF is a
> HORRIBLE place to
> run any of the corporate-centric ASF communities, the list goes on.
>
> What we should aspire to is that, on balance, we're an excellent place
> for the kinds of
> communities that have an affinity to our governance model (and
> license) but that's
> about it.
>
>> I think it’s a sign that there was something wrong in the pre-incubation
>> discussions, certainly some misconceptions. Sure, it’s not the end of the
>> world to go back to the old place, but certainly not the ideal either.
>
> There's as much wrong about pre-incubation as it is with trying to guess whether
> you'd feel at home in a country by looking at travel shows on TV.
>
> Thanks,
> Roman.
>
>
>> On Mon, 17 Jun 2019 at 17:36, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>>
>>> On Mon, Jun 17, 2019 at 1:24 AM Christofer Dutz
>>> <ch...@c-ware.de> wrote:
>>>>
>>>> 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.
>>>
>>> This! Also, I think we should stop being so uptight about communities
>>> trying incubation
>>> and deciding that ASF is not for them. It is a two-ways street when it
>>> comes to education.
>>>
>>>> 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.
>>>
>>> And sometimes you'd return back to your old place after all -- and
>>> that's totally OK.
>>>
>>> Thanks,
>>> Roman.
>>>
>>>> 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" <ge...@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 <da...@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-unsubscribe@incubator.apache.org
>>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubation Pain Points
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Mon, Jun 17, 2019 at 8:51 AM Geertjan Wielenga <ge...@apache.org> wrote:
>
> It’s not really totally OK. People leaving back to their old place feeling
> unhappy and frustrated, how is that totally OK?
I'll stick with Christofer's analogy -- if you come to a new country
thinking that
the roads are paved with gold -- all you're going to get is
frustration and unhappiness.
Not a single place is a paradise on earth.
If, however, you come to the new country with the intent to learn and
see if this
place can *gradually* become your new home -- now you're talking.
Obviously, this doesn't apply to refugees (I guess in our world it
would be corporate
refugees) but it applies extremely well to everyone else.
> How positive is that departing community going to be about Apache? Is that really totally OK?
I'm not sure if you fully realize this, but Apache is a TERRIBLE place
for a whole
bunch of communities (I could totally see this being misquoted -- but
I'm doing it on purpose).
ASF is a HORRIBLE place to run Linux Kernel community. ASF is a
HORRIBLE place to
run any of the corporate-centric ASF communities, the list goes on.
What we should aspire to is that, on balance, we're an excellent place
for the kinds of
communities that have an affinity to our governance model (and
license) but that's
about it.
> I think it’s a sign that there was something wrong in the pre-incubation
> discussions, certainly some misconceptions. Sure, it’s not the end of the
> world to go back to the old place, but certainly not the ideal either.
There's as much wrong about pre-incubation as it is with trying to guess whether
you'd feel at home in a country by looking at travel shows on TV.
Thanks,
Roman.
> On Mon, 17 Jun 2019 at 17:36, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>
> > On Mon, Jun 17, 2019 at 1:24 AM Christofer Dutz
> > <ch...@c-ware.de> wrote:
> > >
> > > 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.
> >
> > This! Also, I think we should stop being so uptight about communities
> > trying incubation
> > and deciding that ASF is not for them. It is a two-ways street when it
> > comes to education.
> >
> > > 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.
> >
> > And sometimes you'd return back to your old place after all -- and
> > that's totally OK.
> >
> > Thanks,
> > Roman.
> >
> > > 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" <ge...@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 <da...@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-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail: general-help@incubator.apache.org
> > > >
> > > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubation Pain Points
Posted by Geertjan Wielenga <ge...@apache.org>.
It’s not really totally OK. People leaving back to their old place feeling
unhappy and frustrated, how is that totally OK? How positive is that
departing community going to be about Apache? Is that really totally OK? I
think it’s a sign that there was something wrong in the pre-incubation
discussions, certainly some misconceptions. Sure, it’s not the end of the
world to go back to the old place, but certainly not the ideal either.
Gj
On Mon, 17 Jun 2019 at 17:36, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> On Mon, Jun 17, 2019 at 1:24 AM Christofer Dutz
> <ch...@c-ware.de> wrote:
> >
> > 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.
>
> This! Also, I think we should stop being so uptight about communities
> trying incubation
> and deciding that ASF is not for them. It is a two-ways street when it
> comes to education.
>
> > 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.
>
> And sometimes you'd return back to your old place after all -- and
> that's totally OK.
>
> Thanks,
> Roman.
>
> > 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" <ge...@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 <da...@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-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> > >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Incubation Pain Points
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Mon, Jun 17, 2019 at 1:24 AM Christofer Dutz
<ch...@c-ware.de> wrote:
>
> 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.
This! Also, I think we should stop being so uptight about communities
trying incubation
and deciding that ASF is not for them. It is a two-ways street when it
comes to education.
> 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.
And sometimes you'd return back to your old place after all -- and
that's totally OK.
Thanks,
Roman.
> 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" <ge...@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 <da...@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-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubation Pain Points
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Wed, Jun 19, 2019 at 6:58 PM Dave Fisher <da...@comcast.net> wrote:
> ...I wonder if we agree on the Core issue?...
To me the core issue, as I said in the "overzealous bureaucracy"
thread is that the Incubator is perceived as a stern gatekeeper of the
ASF, due to the way we act in general.
To fix this I suggested there [1] starting by reformulating the
Incubator's goals in a friendlier and service-oriented way.
Once we agree on that, there's many things that we can do, but having
a strong agreement on such basic principles is the start IMO.
-Bertrand
[1] https://lists.apache.org/thread.html/bee993d70cc29ab412031275571351253ccf59d6dee09e7b9818d779@%3Cgeneral.incubator.apache.org%3E
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubation Pain Points
Posted by Dave Fisher <da...@comcast.net>.
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 <da...@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 <ju...@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-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubation Pain Points
Posted by Dave Fisher <da...@comcast.net>.
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 <ju...@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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubation Pain Points
Posted by Justin Mclean <ju...@classsoftware.com>.
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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubation Pain Points
Posted by Ted Dunning <te...@gmail.com>.
Willem,
There are already tools to help address the most common issues. The common
issues that can't currently be addressed involve human language which is
hard to figure out automatically.
Assuming that these tools can be improved (and they definitely can) who
would you propose do the extending? Remember, nobody is paid to do that.
On Tue, Jun 18, 2019 at 6:27 PM Willem Jiang <wi...@gmail.com> wrote:
> ...
> I know it is harder to provide an unify tool which could be useful for
> all kind of project, but it could address most of common issues if
> IPMC can build the tools together by sharing our experiences.
>
>
Re: Incubation Pain Points
Posted by Willem Jiang <wi...@gmail.com>.
It could be a grown pain for the new podlings if they need to go
through 10+ voting, but it could make the life more easier by
providing some tools to help the podling to find out the issues before
sending out the vote.
I know it is harder to provide an unify tool which could be useful for
all kind of project, but it could address most of common issues if
IPMC can build the tools together by sharing our experiences.
Regards,
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
On Mon, Jun 17, 2019 at 5:37 PM Justin Mclean <ju...@classsoftware.com> wrote:
>
> Hi,
>
> > The biggest fix I’d suggest for the incubator is parallel voting
>
> Worthy of consideration (please start a thread), but IMO we want to be careful it doesn’t overwhelm the IPMC. I’ve seen some RCs got through 10+ votes, and most go through 2 or 3. That’s potentially 2 or 3 or 5x more calls for votes on the IPMC list, unless we modify it somehow or somehow get more IPMC members to vote on releases it’s going to need some careful consideration.
>
> Some discussion on legal discuss and in the last board report may help reduce the requirement for revotes like that.
>
> > after an IPMC vote failed yet again on some aspect that the
> > community is not interested in at all (but should be, but still isn’t).
>
> Or alternatively how could a podling get the community (or it's mentors) to pick up these things before the IPMC vote? In theory your mentors should pick up any issues that the IPMC finds, in practise that doesn't always happen.
>
> Thanks,
> Justin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubation Pain Points
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> The biggest fix I’d suggest for the incubator is parallel voting
Worthy of consideration (please start a thread), but IMO we want to be careful it doesn’t overwhelm the IPMC. I’ve seen some RCs got through 10+ votes, and most go through 2 or 3. That’s potentially 2 or 3 or 5x more calls for votes on the IPMC list, unless we modify it somehow or somehow get more IPMC members to vote on releases it’s going to need some careful consideration.
Some discussion on legal discuss and in the last board report may help reduce the requirement for revotes like that.
> after an IPMC vote failed yet again on some aspect that the
> community is not interested in at all (but should be, but still isn’t).
Or alternatively how could a podling get the community (or it's mentors) to pick up these things before the IPMC vote? In theory your mentors should pick up any issues that the IPMC finds, in practise that doesn't always happen.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubation Pain Points
Posted by Christofer Dutz <ch...@c-ware.de>.
I can see how this can be annoying,
But I also have to see the IPMC workload ... we're raising quite a number of podlings.
Having the votes start in parallel on the podling dev and the general incubator list
would probably not decrease the number of cancelled votes. I would be fine with
allowing parallel votes, if the podlings mentors have voted in favor of the release.
So you start a vote in the podlings dev list and as soon as the mentors have voted +1
You could start the vote in the general incubator list, but not before that.
I mean It's one of the most important jobs of the mentors to thoroughly check the RCs.
If there are realy valid issues for which the vote in the general list is -1ed, that's actually
not really the fault of the Incubator, but could considered the fault of your mentors.
And if these RCs are waived through with serious issues over and over again, I would
Instead start thinking of getting mentors on board, that do the checks before you carry
over.
For exactly that reason I asked Justin to mentor PLC4X when it entered incubation.
He did raise quite a lot of issues, but on the project list and prior to carrying over the
Vote to the general incubator list. And I can't remember a single RC cancelled because
Of IPMC votes on the incubator list.
Chris
Am 17.06.19, 11:15 schrieb "Geertjan Wielenga" <ge...@apache.org>:
I agree and that’s how I see it too — coming to Apache means the assumption
that you’re wanting to adopt its culture. However, there are definitely
very frustrating aspects to that culture. The biggest fix I’d suggest for
the incubator is parallel voting — i.e., start the PPMC vote and IPMC vote
at the same time.
I cannot tell you how many times I’ve wanted to stab myself with a blunt
instrument in the eye after having to restart the PPMC vote yet again (with
less and less enthusiasm from the community and thus less voting and more
time wasting) after an IPMC vote failed yet again on some aspect that the
community is not interested in at all (but should be, but still isn’t).
Gj
On Mon, 17 Jun 2019 at 10:24, Christofer Dutz <ch...@c-ware.de>
wrote:
> 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" <ge...@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 <da...@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-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
>
>
Re: Incubation Pain Points
Posted by Geertjan Wielenga <ge...@apache.org>.
I agree and that’s how I see it too — coming to Apache means the assumption
that you’re wanting to adopt its culture. However, there are definitely
very frustrating aspects to that culture. The biggest fix I’d suggest for
the incubator is parallel voting — i.e., start the PPMC vote and IPMC vote
at the same time.
I cannot tell you how many times I’ve wanted to stab myself with a blunt
instrument in the eye after having to restart the PPMC vote yet again (with
less and less enthusiasm from the community and thus less voting and more
time wasting) after an IPMC vote failed yet again on some aspect that the
community is not interested in at all (but should be, but still isn’t).
Gj
On Mon, 17 Jun 2019 at 10:24, Christofer Dutz <ch...@c-ware.de>
wrote:
> 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" <ge...@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 <da...@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-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
>
>
Re: Incubation Pain Points
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Tue, Jun 18, 2019 at 1:44 PM Justin Mclean <ju...@classsoftware.com> wrote:
> >...at the Incubator level I think there's
> > way to many unclear or badly documented rules.
>
> Nope, sorry that’s at the ASF level....
I agree, the mess is on both sides ;-)
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubation Pain Points
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> In principle I would agree, but at the Incubator level I think there's
> way to many unclear or badly documented rules.
Nope, sorry that’s at the ASF level. The IPMC has some documentation that need clearing up and reducing but that’s not the core issue.
> Could we adopt the Maturity Model [1] as the only thing to which
> podlings must conform to to graduate? Do we need more than that?
While I like the Maturity Model and think it’s very useful, several IPMC members are not in favour of making it standard.
> Focusing on such a clearly defined set of rules and removing anything
> from http://incubator.apache.org/ that's not essential
Other than incubating in name, DISCLAIMER and IPMC voting there’s nothing under http://incubator.apache.org that specifies anything extra that ’s required on top of other ASF policies. Again it’s those policies that podlings need to be in line with by the time they graduate.
thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubation Pain Points
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Hi,
On Mon, Jun 17, 2019 at 10:24 AM Christofer Dutz
<ch...@c-ware.de> wrote:
> ...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...
In principle I would agree, but at the Incubator level I think there's
way to many unclear or badly documented rules.
Could we adopt the Maturity Model [1] as the only thing to which
podlings must conform to to graduate? Do we need more than that?
Focusing on such a clearly defined set of rules and removing anything
from http://incubator.apache.org/ that's not essential in that view
might make our podlings life much easier.
-Bertrand
[1] https://community.apache.org/apache-way/apache-project-maturity-model.html
[2] http://www.apache.org/legal/release-policy.html
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubation Pain Points
Posted by Christofer Dutz <ch...@c-ware.de>.
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" <ge...@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 <da...@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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Incubation Pain Points
Posted by Dave Fisher <da...@comcast.net>.
Hi -
Very interesting talk. It reminds me of Oracle’s donation of OpenOffice.
Would you share your 10 points in text via email?
Best Regards,
Dave
> On Jun 14, 2019, at 3:57 AM, Geertjan Wielenga <ge...@apache.org> wrote:
>
> Just as a quick follow up, I watched this YouTube recording of a session I
> did last year on the NetBeans move to Apache again today and, it's been a
> while since I watched it last, but I think it still really nails it in
> terms of the pain/gain continuum of transitioning a project to Apache, in
> all its bleakness. :-)
>
> https://www.youtube.com/watch?v=Bnznard9Nls
>
> Gj
>
>
> On Thu, Jun 13, 2019 at 10:29 PM Geertjan Wielenga <ge...@apache.org>
> wrote:
>
>> 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 <da...@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-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubation Pain Points
Posted by Geertjan Wielenga <ge...@apache.org>.
Just as a quick follow up, I watched this YouTube recording of a session I
did last year on the NetBeans move to Apache again today and, it's been a
while since I watched it last, but I think it still really nails it in
terms of the pain/gain continuum of transitioning a project to Apache, in
all its bleakness. :-)
https://www.youtube.com/watch?v=Bnznard9Nls
Gj
On Thu, Jun 13, 2019 at 10:29 PM Geertjan Wielenga <ge...@apache.org>
wrote:
> 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 <da...@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-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
Re: Incubation Pain Points
Posted by Geertjan Wielenga <ge...@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 <da...@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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Incubation Pain Points
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Hi,
On Thu, Jun 13, 2019 at 9:10 PM Dave Fisher <da...@comcast.net> wrote:
> ...Here are some thoughts I have to improving Incubation....
FWIW, to give additional context for ASF Members, there was also a
discussion about this started by Incubator PMC members, on the board@
list: http://s.apache.org/zipkin_mentors_feb18
(as mentioned, accessible to ASF Members and PMC Chairs only, but I
think most IPMC members are ASF Members)
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org