On Sun, Mar 15, 2020 at 12:59 PM Justin Mclean <jus...@classsoftware.com> wrote: > > Hi, > > > 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. > > In my experience this has the opposite effect, it discourages newcomers from > contributing. You want to help contributors out so that they become > committers over time. But as they say you milage may vary. You want a low bar > for new people to be able to become contributors and to become committers.
So what you suggest it that we as committer don't need disscuss anything with the contributor, we just need take his PR and do what we think the right modification then merge directly. > > > It's better to limit this direct modification in some special case, > > for example the owner don't response PR for a long time. > > If they don’t respond it mean you have driven them away, and that teh best > time to ask yourself what could you have done differently to keep them > involved? I talk this example just because I saw some people send a PR and then forget it in other github project, the contributor has to correct the issue in PR by self sometime. >From the recent PR, most contributor will like to dissuss his PR and improve >it: https://github.com/apache/incubator-nuttx/pull/556 https://github.com/apache/incubator-nuttx/pull/550 https://github.com/apache/incubator-nuttx/pull/503 The aboved PR has many constructive dissussion between the contributor and commiter before they get the final consensus. > > Thanks, > Justin
