Problems with Committer Invite Documentation

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Problems with Committer Invite Documentation

leerho@gmail.com
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>.

   - 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 [[hidden email]]
> 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.


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.



   - 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.




   - 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.

I would be happy to submit these changes as a PR but someone will have to
tell me where to do this.

Cheers,

Lee.
Reply | Threaded
Open this post in threaded view
|

Re: Problems with Committer Invite Documentation

John D. Ament-2
On Tue, Aug 4, 2020 at 4:19 PM leerho <[hidden email]> 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 [[hidden email]]
> > 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.


>
> 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).


>
>
>    - 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.
>
Reply | Threaded
Open this post in threaded view
|

Re: Problems with Committer Invite Documentation

Dave Fisher


> On Aug 4, 2020, at 1:31 PM, John D. Ament <[hidden email]> wrote:
>
> On Tue, Aug 4, 2020 at 4:19 PM leerho <[hidden email]> 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 [[hidden email]]
>>> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Problems with Committer Invite Documentation

leerho@gmail.com
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.

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 <[hidden email]> wrote:

>
>
> > On Aug 4, 2020, at 1:31 PM, John D. Ament <[hidden email]> wrote:
> >
> > On Tue, Aug 4, 2020 at 4:19 PM leerho <[hidden email]> 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 [[hidden email]]
> >>> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Problems with Committer Invite Documentation

Justin Mclean
Hi,

> I searched incubator.a.o and could not find any comparable documentation
> that is step-by-step with example template emails.  

See:
http://incubator.apache.org/guides/ppmc.html#adding_new_committers

(Which points to other ASF documentation)

> 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?

PPMC members can be moderators for that list as well, I would suggest you add some to moderate that list. If your mentors are not being active then find out why they are not being so, it may be that your project needs a new mentor or two.


> 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 project don’t operate that they, and any commit can be easily reverted so many project don’t see that advice as ill advised.

> 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!

Pull request and patches are welcome but just consider that not all projects operate in exactly the same way.

Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Problems with Committer Invite Documentation

Dave Fisher
In reply to this post by leerho@gmail.com


> On Aug 4, 2020, at 2:52 PM, leerho <[hidden email]> 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.
[hidden email] <https://whimsy.apache.org/roster/ppmc/committer/chenliang613>, [hidden email] <https://whimsy.apache.org/roster/ppmc/committer/kamaci>, [hidden email] <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 <[hidden email]> wrote:
>
>>
>>
>>> On Aug 4, 2020, at 1:31 PM, John D. Ament <[hidden email]> wrote:
>>>
>>> On Tue, Aug 4, 2020 at 4:19 PM leerho <[hidden email]> 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 [[hidden email]]
>>>>> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Problems with Committer Invite Documentation

Matt Sicker
The private list is important to watch anyways as a project that can't
provide oversight to said mailing list is typically in danger of
dying. Adding moderators for the list would certainly help.

On Tue, 4 Aug 2020 at 17:56, Dave Fisher <[hidden email]> wrote:

>
>
>
> > On Aug 4, 2020, at 2:52 PM, leerho <[hidden email]> 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.
> [hidden email] <https://whimsy.apache.org/roster/ppmc/committer/chenliang613>, [hidden email] <https://whimsy.apache.org/roster/ppmc/committer/kamaci>, [hidden email] <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 <[hidden email]> wrote:
> >
> >>
> >>
> >>> On Aug 4, 2020, at 1:31 PM, John D. Ament <[hidden email]> wrote:
> >>>
> >>> On Tue, Aug 4, 2020 at 4:19 PM leerho <[hidden email]> 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 [[hidden email]]
> >>>>> 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: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
>


--
Matt Sicker <[hidden email]>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]