Replies inline: > On Jul 12, 2019, at 3:49 AM, Justin Mclean <jus...@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-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
