From general-return-70125-archive-asf-public=cust-asf.ponee.io@incubator.apache.org Thu Jul 11 02:00:56 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id F0CF118064A for ; Thu, 11 Jul 2019 04:00:55 +0200 (CEST) Received: (qmail 116 invoked by uid 500); 11 Jul 2019 02:00:53 -0000 Mailing-List: contact general-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: general@incubator.apache.org Delivered-To: mailing list general@incubator.apache.org Received: (qmail 104 invoked by uid 99); 11 Jul 2019 02:00:53 -0000 Received: from Unknown (HELO mailrelay1-lw-us.apache.org) (10.10.3.159) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 Jul 2019 02:00:53 +0000 Received: from [192.168.1.120] (pool-173-48-227-89.bstnma.fios.verizon.net [173.48.227.89]) by mailrelay1-lw-us.apache.org (ASF Mail Server at mailrelay1-lw-us.apache.org) with ESMTPSA id B02A7820C for ; Thu, 11 Jul 2019 02:00:49 +0000 (UTC) From: Joshua Poore Content-Type: multipart/alternative; boundary="Apple-Mail=_C57D26F8-A3E8-44FB-A43B-3FE0943F9159" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: New disclaimer text Date: Wed, 10 Jul 2019 22:00:49 -0400 References: <3D44198D-D3D2-43CB-B5DA-AB8FE2591447@comcast.net> <1562188106.2079161.1669413632.0DDB5260@webmail.messagingengine.com> <6BEFB565-833C-4CC7-85FE-5821AA85199F@classsoftware.com> <05290A2B-1CF7-4B80-9E54-C6242E597FD1@classsoftware.com> To: general@incubator.apache.org In-Reply-To: <05290A2B-1CF7-4B80-9E54-C6242E597FD1@classsoftware.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) --Apple-Mail=_C57D26F8-A3E8-44FB-A43B-3FE0943F9159 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I=E2=80=99m also a PPMC member (Apache Flagon). It seems the Incubator = is at an inflection point=E2=80=94been tracking how different threads on = general@ are capitulating on issues of identity and process. Gian=E2=80=99= s points are SPOT on, but so are Justin=E2=80=99s. I have some = reconciliatory thoughts and suggestions, which I=E2=80=99m embedding in = line: > On Jul 10, 2019, at 5:44 PM, Justin Mclean = wrote: >=20 > Hi, >=20 >> Speaking as a member of a currently-incubating project (Apache Druid) = where >> we have always strived to do releases with no known licensing issues, = the >> text sounds needlessly scary to downstream consumers. > And that may be the problem with a one solution fits all process. It = has been suggested before we let podlings choose which release process = they want. However that may get too complex and make voting on releases = inconsistent. +1 on both points. The value we (podlings) take out of the Incubator is = mentorship and scaffolding in adopting the Apache Way. In doing so, the = =E2=80=9CWay=E2=80=9D, its processes, and the policies that shape those = processes are meant to improve our offerings (code), our adoptability, = and grow a sustainable community. Adding an additional disclaimer that = we may have known issues adds additional barriers to adoption and = community growth. An Incubator by definition takes on = risk=E2=80=94infrastructure, time, and opportunity, sunk, and = operational costs=E2=80=94to help nurture its participants. That risk is = directly yoked to the participants=E2=80=99 value gains from = participating. Placing additional barriers to growth and adoption to = eliminate the ASF=E2=80=99s risk breaks the incubator model altogether.=20= >=20 >> IMO this disclaims too much, and would chill adoption of incubating >> software by people that care about having clean licensing. PPMCs = should be >> able to say "we believe this release is clean and have vetted it = using a >> normal Apache vetting process" or maybe even "we have vetted this = release >> and it is clean other than the following list of known issues". If = they >> can't say one of those two statements, then maybe it's not time to do = their >> first release yet. >=20 > The idea is to allow podlings to make releases that may not comply = with policy. Have a hard switch from your releases doesn=E2=80=99t = comply to everything must comply is too difficult for some podlings. +1 on both point and counterpoint. This disclaims too much and there = needs to be compliance to policy. The risk the Incubator needs to take = is that 100% compliance is an eventual, but measurable goal. Yet, the = Incubator needs a means to manage risk. A better model than the = disclaimer: progressively incentivize compliance with metrics.=20 Here=E2=80=99s one way for the ASF Incubator: Apache=E2=80=99s key = marketing point is the Apache Way. Break down critical processes, = determine key performance indicators against those processes, and = centrally track metrics (license compliance, community participation, = release compliance, notice, keys, whatever, whatever). Then build some = Apache-branded badges that expose those metrics publicly so that all = your podlings can stick them on their GitHub READMEs, same way as we = have for CI, test coverage, etc., etc. Doing something like this, the = Incubator is using the brand to incentivize organic compliance and = manage risk. Implicit in this usage of the Apache brand is communication = that podling projects are not fully endorsed by Apache, but the project = being looked after by a trusted organization. Podlings have clear = metrics that they can communicate and take actions to move the needle = on. Podlings have a way to discriminate themselves from other = open-source projects and from other podlings by showing positive values = on their badges. This whole model provides a discriminator for all = podlings in that other open-source projects don=E2=80=99t have the = infrastructure to communicate these metrics; these badges=E2=80=99 = existence engenders trust in the ASF & Incubator brand(s) and skepticism = about non-Apache projects. Podlings who work to budge metrics can = communicate to consumers and potential community members and continually = brings them in line with Apache policy=E2=80=94the value they get from = the incubator is now directly proportional to compliance (Incubator risk = reduction). The Incubator also gets a better way to track incubation = status, direct special attention to podlings that are bottoming out = (before removal) and podlings that are showing progressive improvement. = This method (or similar) tells the public how much trust Apache has in a = particular podling. The additional disclaimer communicates that Apache = has little trust in its podlings, at large. Maybe this is too much technically (I doubt that), maybe this isn=E2=80=99= t the best or only way to do this, but the key theme here is: = measurable, progressive improvement. That should be sufficient to stay = in the Incubator and necessary to graduate. Importantly, = =E2=80=9Cprogressive=E2=80=9D means that metrics are updated regularly = and not just at the time of release...=20 >=20 >> And yeah, as a few others have mentioned, I believe that a more = streamlined >> voting process >=20 > That I think is a different issue, ands may be best to start another = thread on that. The main issue here is that IPMC members votes are = binding, and not all mentors (who are IPMC members) vote on releases, so = podlings need votes from the wider IPMC members to make releases (in = about 90%+ of cases). There been a few ideas on how to improve this, = including one approved method (but no podlings have take that up yet). >=20 -1. These are connected issues: Mentors are IMPCs "tip of the spear" for = managing compliance risk and for adding value to podlings. I have so = much respect for Justin and other IPMC regulars who tirelessly volunteer = and monitor general@, dig into minor releases to test builds and check = compliance. It=E2=80=99s heroic, but heroes are a sign of struggling = operations in orgs, and heroes burn out. Their valuable time is better = spent institutionalizing knowledge and skills: making mentors' jobs = easier with templates, documentations, infrastructure projects. In doing = so, the Incubator empowers PPMCs, engenders self-sufficiency and gives = mentors bandwidth to progressively track compliance at regular = intervals, VOTE on releases (with expediency), swoop in to help with the = tactical issues that come up, and actually mentor podlings on how to = steadily grow with wisdom and experience. IMHO: the thing the needs to be discussed in a different thread is how = the Incubator supports and incentivizes engaged mentors. Speaking from = experience: engaged mentors are magical gifts from above. Losing mentors = during critical junctures is terrifying because there is so much to = learn and its hard to find documentation and examples for how to do = things right. Its hard to know what you have permission to do and taking = a risks to do certain things without mentors can result in shame and = worry that you=E2=80=99ll look like you're struggling if feel they're = done wrong. These issues are inexorably intertwined because mentors are = at the heart of managing Incubator risk/compliance and value to = podlings. Ever chasing the Apache Way, -J > Thanks, > Justin > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org > For additional commands, e-mail: general-help@incubator.apache.org >=20 --Apple-Mail=_C57D26F8-A3E8-44FB-A43B-3FE0943F9159--