incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joshua Poore <poor...@me.com.INVALID>
Subject Re: New disclaimer text
Date Fri, 12 Jul 2019 17:30:14 GMT
Replies inline:

> On Jul 12, 2019, at 3:49 AM, Justin Mclean <justin@classsoftware.com> wrote:
> 
> Hi,
> 
>> Adding an additional disclaimer that we may have known issues adds additional barriers
to adoption and community growth.
> 
> I think the question to be asked is does that add barries more than having to have 100%
compliant releases? I think the answer may depend on the podling. Have does that work out
for 50 odd podlings?

I’m looking at this from a corporate investment perspective, having some insights into that
process: you’re right, each podling has a different market with different community dynamics.
I’m not going to speculate as to the base-rates. What I can say is that the ASF needs to
be (and probably is) tracking the growth in the tech start-up, small-business market. The
Apache license is highly desirable by small business and those working under VC, as is the
`Apache` brand (even US gov’t agencies are looking at this more closely). This is going
to be a huge potential drivers for growth in projects and communities. Looking at things from
this perspective, if there is an additional disclaimer that make an Apache Incubator project
look riskier to adopt than some other junk on GitHub with more than 10 stars, then I see an
unnecessary barrier in exploiting how the growing tech market can accelerate the growth of
open-source projects. Open-source no longer just about a bunch of folks who love keeping software
free and open, or folks to love collaborating, its also about driving technology markets in
strategic ways. I hold all three of these interests.

> 
>> Here’s one way for the ASF Incubator: Apache’s 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).
> 
> I really like the idea, would you be willing to work on it further?

I would, and I will, but I can’t do it all on my own. Some of the back-end stuff and navigating
the INFRA reqs will be beyond my skills. However, I can contribute and at least work on marshaling
other volunteer resources, managing tickets, requirements generation, and drawing in examples
from some of the existing badges that are so popular in say, the node.js community. My action
to start a thread in the near-term on this for discussion, I might need your help in directing
other podlings PPMCs to the thread so that we get the best range of requirements and levels
of interest from the podlings. I will also add a confluence page on this proposal.

> 
> Some things to consider. I don’t know it we have enough volunteer time to implement
something along those line or if we could come out with clear metrics to suit all podlings.
However in some ways this work has already been done with the maturity model. There are issues
this this as well a) not all IPMC members or podlings think it should be used so so it's optional.
b) we’ve had podlings fill it in and ask to graduate that were clearly not ready to graduate.

That’s OK. We’ll run it to ground. At minimum, I think the conversation will be a forcing
function to really ascertain whether the larger podling community cares about the disclaimer
as much as a few vocal committers.

> 
>> The additional disclaimer communicates that Apache has little trust in its podlings,
at large.
> 
> About 1 in 5 podling releases put up fro IPMC have serious issues and have previously
have attracted -1 votes by IPMC members. If we allow those to be released then I think we
need to add something to the the disclaimer, we just need to work out a balance.

Communication of distrust isn’t the same thing as how we trust something right now. It's
clear that if these compliance issues are really risks from a legal perspective then you have
very good reason to distrust some podlings. How the Incubator communicates that distrust and
its implications for giving podlings a real shot at success is the crux of the issues. My
point is that any Incubation model requires some element of risk because those risks are precisely
the value adds to incubator participants. Beyond a balance in accepting risk, we need to help
find the Incubator better, more efficient ways of managing risks. I suppose that’s the tl;dr
version of the manifesto I accidentally wrote the other night.

> 
>> -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’s heroic, but heroes are a sign of struggling operations
in orgs, and heroes burn out.
> 
> I’ve yet to see any proposal that deals with the issue of how it would get around that
only PMC members votes are binding. I don’t see voting in all PPMC member as PMC member
working (we get complaints that he IPMC is already too large) and I don’t think the board
would allow a TLP to ignore that particular bylaw. I’m open to suggestions.

My point is only that mentors will help manage risks, and there is a known issue right now
for getting binding votes from PPMC. Like you, I’m not sure that the answer is to change
voting policies. I actually love submitting our work to objective scrutiny. It makes me feel
better about releases. However, if IPMC members who sit on PPMC aren’t VOTING or signing
REPORTs, then its a volunteer incentive problem too. I don’t know a silver bullet method
for how to incentivize mentors in a not-for-profit, strict volunteer organization. But, it's
a thing that should be raised as discussion. I’ll contribute to that discussion and share
any suggestions that pop up.  

> 
>> Their valuable time is better spent institutionalizing knowledge and skills: making
mentors' jobs easier with templates, documentations, infrastructure projects.
> 
> We do quite a bit of that as well.

As I said, you’re heroes and inspiring at that. As a committer, I’m not worried about
what you’re doing, or how you’re doing it. I’m worried about how much time you spend
on stuff you want to do and things you think you should be doing, not just what you need to
be doing. When heroes don’t get to do what challenges them, grow them, and fulfills them,
they start disappearing. That’s what I worry about because I see the strain that disappearing
binding votes and eyes on licenses and notice files is adding to general@, and I worry about
the heroes disappearing for burn out.  

> 
>> 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.
> 
> If you have engaged mentors then that should be no issue, the last checkbox before graduation
is that you don’t need mentors anymore and can wrk out things for yourself that are in line
with how other ASF projects operate and the Apache Way. If you feel like that then perhaps
your mentors haven’t completed their job.

I think you made my point better than I did. I would add that it’s clear that a number of
mentors (across the Incubator) just aren’t showing up, which means that they’re not doing
their job. That puts burden on PPMC and IPMC processes (releases, reports), shifts the workshare
up to IPMC to make sure things are compliant. Now, I fully respect that my subjective experience
probably doesn’t cover all others, but I can’t image that some other committers/PPMC aren’t
feeling some of the same things. When committers and PPMC have questions they don’t know
the answers to, can’t find the right documentation, or can’t deduce the right thing to
do because documentation describes process and policy, but doesn’t give context as to why
it exists, then any reasonable human can feel an unfamiliar paralysis or irreducible uncertainty
that slows growth. We learn without guidance, and sometimes painfully through trial and error,
which can be painful in public both in front of general and our own communities for many of
the same reasons we worry overhe disclaimer. This is where this thread unravels and needs
to be picked up elsewhere. However, the relevant point is that when mentors don’t show up
or don’t themselves know the right processes, that contributes to your 1:5 compliance problem.
A disclaimer doesn’t fix that, IMO. It's the nuclear option that wipes the map clean of
compliance risk and doesn’t address the problems and strains that prevent compliance from
improving at the PPMC level before it becomes IPMCs problem.
> 
> Thanks for your thoughts,

Thanks for listening. I wouldn’t contribute to this thread if I didn’t care about the
incubator, and I do. It's a great organization with great people, and I’m happy to help
nurture it in the same way that it is nurturing Flagon.

> 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


Mime
View raw message