+1 I think this proposal could help a lot with how feedback is perceived by podlings!
On Mon, Feb 25, 2019 at 11:51 PM Myrle Krantz <my...@apache.org> wrote: > Some podlings want or need feedback on their releases before they are ready > to make official Apache releases. They want to discuss releases that are > not yet ready for a VOTE, or that they are not sure they are ready for a > vote. When such a review is actively requested by the podling, it sets up a dynamic where the recipient can more easily accept and act on the feedback they receive, without losing face. Contrast that with the present, where feedback on releases most often arrives at the time of a release VOTE, where it can be interpreted as punitive. Naturally, we believe that this feedback is essential and a valuable contribution to the podling. So we should set ourselves up to increase the likelihood that it will be perceived that way! Now, it may be the case that a podling doesn't avail itself of the opportunity to request a pre-release review. But so long as they knew about that the service was available, even though they might feel resentful they can only complain so loudly. I read elsethread that some podlings already pro-actively seek out review, which speaks well of such podlings and their Mentors. But I submit while that these conscientious, well-informed podlings will also benefit from system better designed to be constructive and positive, they are not the ones most likely to become disgruntled or even end up in crisis. The linchpin of this proposal is reliable outreach to those podlings who would not seek out this service on their own. If such a podling is not informed, and then later runs into trouble, we will have missed an valuable opportunity. Therefore, I'd suggest that an email to the dev list on this subject ought to be on a mentoring checklist. > Arguments for this proposal: > > * It's a very small change which may make it easier to implement than some > of the "throw it all away and start over" proposals circulating, but... > * It doesn't prevent us from making other larger changes. +1 > * It's not a rule. It's an offering of an additional service + an > incremental reduction in stringency of the incubator. +1, and I'd add that it corrects how the Incubator should see itself -- instead of an enforcer, as a provider of services to podlings. > * It captures some of the value in what we are doing now while increasing > the degrees of freedom provided to podlings. > * It is consistent with our values of transparency, collaboration, > community, pragmatism, meritocracy, and charity. +1, well said! Marvin Humphrey --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
