Hi - > On Aug 12, 2019, at 6:41 AM, Matt Sicker <boa...@gmail.com> wrote: > > This observer IPMC role sounds interesting. That would make it less > intimidating for people who can help verify a generic release but are > unfamiliar with the domain itself.
We currently have Shepherds to look into podlings at report time. This is for how they are doing in the community. If we have an observer role, I don’t think it needs to be formal. It would simply be to be a freelance release auditor. Perhaps those people willing to be an extra IPMC on a community dev@ vote could subscribe to a special mailing list. When a podling starts a release and suspects they don’t have enough Mentors engaged they can send a email to revi...@incubator.apache.org requesting help. (Some might say use general@ that’s ok too.) This is similar to Mryle’s REVIEW proposal. It just becomes about timing. Also, if a podling regularly has trouble with enough IPMC votes for their dev@ releases then a discussion is needed about finding new volunteer mentors. Regards, Dave > > On Mon, Aug 12, 2019 at 03:37, Julian Feinauer <j.feina...@pragmaticminds.de> > wrote: > >> Hi, >> >> I'm answering to this (old) thread as the new one branched up with a >> different topic. >> Personally, during my time in the first podling I learned a lot by doing >> Apache Releases. >> First, as contributor, then as PPMC and finally as RM. >> And this is something valuable and if a project wants to become a TLP >> something people have to learn. >> And not only one or two but better every PPMC member (and some even able >> to RM). >> >> So I suggest to encourage Podlings as much as possible to to ASF releases. >> I would suggest to solve all the current issues by setting the rules up in >> a way which lets podlings have (at least) 3 +1 IPMC votes in their PPMC >> Vote which are then carried over and make the IPMC Vote basically "lazy >> consensus". >> >> To do this I would suggest to set up / change the "Mentor Guideline" that >> a Mentor "should" vote on PPMC releases. >> Furthermore, in addition to 3 (active?!) Mentors we could add 2-3 >> "assessors" or "observers" (from the IPMC) who do not help actively but are >> on the list and whos dutie is to support Releases. >> That would make a pool of 5-6 IPMC members for each podling which should >> be encouraged to VOTE on releases. >> >> Then, we could, step by step, tackle podlings to bring their Vote to the >> IPMC only if they have 3 +1 votes. >> >> This would allow us to keep all global rules of the ASF as is and only >> change Incubator "internals". >> I think we should really start to see Mentoring as something which needs >> time and work and which people should only call in if they feel like they >> can do. >> For everything else we could have this "observer" role where people that >> find the project interesting could simply take to watch and monitor it but >> with their Votes also help the incubator a lot. >> >> Julian >> >> Am 12.08.19, 02:46 schrieb "Greg Stein" <gst...@gmail.com>: >> >> On Sun, Aug 11, 2019 at 6:32 AM Justin Mclean < >> jus...@classsoftware.com> >> wrote: >> >>> Hi, >>> >>>> I see no problem with using our infrastructure to distribute F/OSS >>>> materials. Why would the Foundation want to be against that? If it >> is >>>> labeled properly, then ... roll with it. >>> >>> It often isn’t labelled properly. There’s a reasonable risk that >> some of >>> what would be placed there and distributed isn’t actually F/OSS. >> >> >> And what would be the blowback of something on our server with >> incorrect >> information? Very little. Mostly, we'd just move on. Maybe we delete >> it. >> >> >>> I can point you to several example of this. I’m not sure how the >> incubator >>> (or the board) would feel about that risk, so that would be >> something we >>> would be need to consider further. Also >> >> >> Welp. Then I will pose that question, rather than this endless >> pontificating about "risk". >> >> >>> while Jane and John may be fine with that, a lot of companies that >> use >>> Apache releases may not be. >>> >> >> I already acknowledged that. Many people could use software regardless >> of >> its licensing. The license typically only matters in *redistribution* >> scenarios. Things like the AGPL affect *usage*, but that is very, very >> atypical. I'd think 99% of downstream could use our software, even with >> gummed-up licensing. >> >> >>>> You're conflating *learning* with *releases*. These can be handled >>> separately. >>> >>> How exactly? >> >> >> You're saying that releases are the control point to learning. I say >> just >> let the releases go. >> >> You want to teach? Then you can use the releases like "that wasn't >> good. >> next time: do A and B". Over time, releases will get fixed. But the >> IPMC >> should not have to manage the releases. >> >> Cheers, >> -g >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> > -- > Matt Sicker <boa...@gmail.com> --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
