On Sun, Mar 15, 2020 at 5:31 AM Gregory Nutt <spudan...@gmail.com> wrote: > > Question: Github permits committer to modify the content of > contributors PRs through this mechanism: > https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/committing-changes-to-a-pull-request-branch-created-from-a-fork > > I appreciate that this may be expeditious, but it feels like bad > etiquette to me. It seems like we should accept what the contributor > has offered, accept the changes, or allow them to modify the changes. >
Yes, this is last resort. It's better to discuss PR in the github and let the contributor fix the problem by self. The collaboration model can decrease the divergence and improve the community health. > I can also appreciate that there may be cases where a committer requires > help to get things right, but that would be a special case. > > Do we really want to encourage this as standard practice. My gut says > no, but I can also change my gut to match the consensus of the PPMC. > It's better to limit this direct modification in some special case, for example the owner don't response PR for a long time. It's also important to try to get the permission before the committer modify contributor's PR. > Whatever should be decided, the conclusion should be included in the > workflow document: > https://cwiki.apache.org/confluence/display/NUTTX/Code+Contribution+Workflow. > If it is not permitted by the workflow, then it is forbidden, right? > > I don't think we need to vote on this here. The proper text needs to be > included in the workflow document which we will, eventually approve by vote. > Yes, it's better to update the workflow document in the note section, let the community make a vote for the whole worflow. > Greg >
