incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <w...@apache.org>
Subject Re: Problems with Committer Invite Documentation
Date Tue, 04 Aug 2020 22:55:12 GMT


> On Aug 4, 2020, at 2:52 PM, leerho <leerho@gmail.com> wrote:
> 
> John,
> Thank you for your comments.
> 
> First understand that this site (community.a.o) is maintained by comdev.
>> Podlings should be following the processes at http://incubator.apache.org/
> 
> 
> I searched incubator.a.o and could not find any comparable documentation
> that is step-by-step with example template emails.  There are several pages
> devoted to educating new committers, but I could not find much on inviting
> new committers.  So in the absence of good documentation I used what I
> could find.   Also, I have never read anywhere that podlings should not be
> reading or following the ASF documentation.  Presumably, the ASF
> documentation preempts incubator documentation in most cases.
> 
> No.  Why do you think it will disappear into the "bit-bucket"?  The
>> candidate would have the email in their inbox and would be able to archive
>> it/save it for reference however they choose fit.
> 
> 
> Because it has been over 24 hours since our candidate replied and it still
> does not show up in our private@ mail list. If our mentors have the
> responsibility to moderate the private list, why is it that none of our 5
> mentors have not forwarded it?  Whether it is technically a bit-bucket or
> not is irrelevant.  If our mentors don't moderate the list and forward an
> important email such as a committer invite, it is effectively a
> bit-bucket!   So our candidate is sitting waiting for the next steps and is
> hearing nothing!  That is unacceptable.

Not all mentors are moderators. I am not.

These three are moderators.
chenliang613@apache.org <https://whimsy.apache.org/roster/ppmc/committer/chenliang613>,
kamaci@apache.org <https://whimsy.apache.org/roster/ppmc/committer/kamaci>, kenn@apache.org
<https://whimsy.apache.org/roster/ppmc/committer/kenn>

The information is here: https://whimsy.apache.org/roster/ppmc/datasketches

> 
> WRT:  Being a committer enables you to more easily make changes without
> needing to go through the patch submission process. --- (A ill-advised
> implication)
> 
> That's a fair point, but not all projects follow this pattern.  In
>> addition, the template is free to be modified by each project, you're under
>> no obligation to follow the published format verbatim; so if your project
>> chooses to invite someone and wants to reword the text you can.
>> 
> 
> I recognize that these templates can be changed by the user.  But you are
> missing my point.  Why start with a recommendation that is ill-advised to
> start with?  Many folks simply copy these templates making as few changes
> as possible without reading the content and thinking about the
> implications.  And I have proof of this happening with senior ASF folks.
> 
> I am a bit puzzled why you are pushing back so hard on my recommendations.
> I am a great fan of the ASF and I just want to improve the documentation
> and make it better!
> 
> Regards,
> Lee.
> 
> 
> 
> On Tue, Aug 4, 2020 at 1:54 PM Dave Fisher <wave@apache.org> wrote:
> 
>> 
>> 
>>> On Aug 4, 2020, at 1:31 PM, John D. Ament <johndament@apache.org> wrote:
>>> 
>>> On Tue, Aug 4, 2020 at 4:19 PM leerho <leerho@gmail.com> wrote:
>>> 
>>>> Folks,
>>>> 
>>>> It is our first time going through the recommended New Committer process
>>>> and we have uncovered some significant problems with the documentation
>>>> <https://community.apache.org/newcommitter.html#new-committer-process>.
>>>> 
>>>> 
>>> First understand that this site (community.a.o) is maintained by comdev.
>>> Podlings should be following the processes at
>> http://incubator.apache.org/
>>> 
>>> 
>>>>  - The most serious problem is step A: of the "Committer Invite
>> Template"
>>>>  on the above page:
>>>> 
>>>> A. This personal invitation is a chance for you to
>>>>> accept or decline in private.  Either way, please
>>>>> let us know in reply to the [private@project.apache.org]
>>>>> address only.
>>>>> 
>>>>> This is a potential disaster, since the candidate will not have read
or
>>>> write privileges to the private mail list, the candidate's reply will
>>>> simply disappear into the bit-bucket! I would recommend changing this
>>>> paragraph to:
>>>> 
>>>> A. Please reply directly to me if you wish to accept (or not accept)
>> this
>>>>> invitation.
>>>> 
>>>> 
>>> No.  Why do you think it will disappear into the "bit-bucket"?  The
>>> candidate would have the email in their inbox and would be able to
>> archive
>>> it/save it for reference however they choose fit.  private mailing lists
>>> may have moderation in place, but since it's a legitimate email the
>>> moderators of the list should moderate it through if it does get
>>> moderated.  The acceptance should also be on the podling's private list
>> to
>>> allow the ASF to have a permanent record of the acceptance.
>> 
>> I have moderated numerous such requests in the past. Usually within 24
>> hours, but occasionally within 104 hours.
>> 
>> I have a Smart Mail filter to make sure that I see all moderation emails
>> even though the vast majority are spam.
>> 
>>> 
>>> 
>>>> 
>>>> Presumably the person sending this message will be someone from the PMC
>> /
>>>> PPMC that the candidate already has had some contact with. Also,
>> hopefully,
>>>> the sender has enough good sense to not CC non-private mail lists or
>> other
>>>> people on the invite, which will make the exchange as private as
>> possible.
>>>> 
>>>> 
>>> Yes, the person sending the invite needs to be on the PMC/PPMC.
>> Typically
>>> this is done by whoever actually did the nomination but there is no
>> formal
>>> rule about who must or must not send it (in some TLPs I think they expect
>>> the chair to do it, podlings don't have chairs).
>> 
>> Typically a response is required in 30 days and the PPMC and Mentors will
>> need to track the result.
>> 
>> Sometimes a nominee has to ask their company if they can sign an ICLA and
>> not every one can.
>> 
>> Regards,
>> Dave
>> 
>>> 
>>> 
>>>> 
>>>> 
>>>>  - The next problem is the wording of the first sentence of the
>>>>  2nd paragraph:
>>>> 
>>>> Being a committer enables you to more easily make
>>>>> changes without needing to go through the patch
>>>>> submission process.
>>>>> 
>>>>> 
>>>> This is basically recommending bad programming practice! We encourage
>> all
>>>> our committers to use the PR and review process on all but the most
>> trivial
>>>> commits (e.g., documentation typos).  I would recommend simplifying this
>>>> sentence to:
>>>> 
>>>> Being a committer grants you write access to the project repositories.
>>>> 
>>>> 
>>>> 
>>> That's a fair point, but not all projects follow this pattern.  In
>>> addition, the template is free to be modified by each project, you're
>> under
>>> no obligation to follow the published format verbatim; so if your project
>>> chooses to invite someone and wants to reword the text you can.
>>> 
>>> 
>>>> 
>>>> 
>>>>  - This next issue is somewhat a matter of style, but I would recommend
>>>>  replacing the entire section "B" with:
>>>> 
>>>> B. If you accept, you will receive a follow-up message with the next
>> steps
>>>>> for establishing you as a committer.
>>>> 
>>>> 
>>>> 
>>>> The above changes will make the invite letter simpler and more
>>>> straightforward.
>>>> 
>>>> 
>>> Once you've invited the person to be a committer, they should be able to
>>> submit the ICLA on their own.  Someone on the PMC/PPMC shouldn't need to
>>> tell them how to do it, but the instructions included in B are pretty
>> clear
>>> and help that committer figure out how to submit the forms as needed.
>>> 
>>> 
>>>> I would be happy to submit these changes as a PR but someone will have
>> to
>>>> tell me where to do this.
>>>> 
>>>> Cheers,
>>>> 
>>>> Lee.
>>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>> 
>> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message