> I think the question to be asked is does that add barries more than having to > have 100% compliant releases?
Is this a current requirement that is written down somewhere and generally practiced? Am Fr., 12. Juli 2019 um 09:49 Uhr schrieb Justin Mclean <jus...@classsoftware.com>: > > 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? > > > 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? > > 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. > > > 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. > > > -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. > > > 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. > > > 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. > > Thanks for your thoughts, > 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
