On Tue, Aug 4, 2020 at 4:19 PM leerho <lee...@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 [priv...@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. > > 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. >
