That is based on review, I think. No better way. But I need to be clear, commits number is just couls help evaluation, not the metric, definitely not a rule.. Such as in SkyWalking, we have committer with very little codes contribution. Even, we may promote someone just for helping community, with no codes.
Sheng Wu Apache SkyWalking, Sharding-Sphere From Wu Sheng 's phone. ------------------ Original ------------------ From: [email protected] <[email protected]> Date: Thu,Nov 22,2018 10:41 AM To: dev <[email protected]> Subject: Re: Recommand to open `Squash and merge` as default merge in GitHub repo Good suggestion! We can try to use milestone to management issues and use `squash and merge` for the pull request. One question for `squash and merge` for the pull request. If committer find some codes or documents are missing, but the pr has already merged, any suggestion for this situation? ------------------ Liang Zhang Apache Sharding-Sphere & Dubbo ???? Sheng Wu <[email protected]> ??2018??11??21?????? ????11:02?????? > Hi, initial committer > > > I have known, we are going to move the repos. I think we could expect > ShardingSphere will have more and more contributors from out of initial > committer team. In our Apache releases, we need to provide CHANGELOGS, ref > SkyWalking's[1]. We should make commit logs matching the issues and > changelogs. > > > Also, in the future, we need to evaluate new committer and PPMC, `squash > and merge`makes your commits[2] list more reliable. Because in my personal > experiences, some one will submit a lot of commits in PR. Others will > rebase, especially the one has more open source experiences. Make commits > at least equal the number of PR merged. > > > Of course, this is only my suggestion. > > > > > [1] https://github.com/apache/incubator-skywalking/blob/5.x/CHANGES.md > [2] https://github.com/sharding-sphere/sharding-sphere/graphs/contributors > > > ------------------ > Sheng Wu > Apache SkyWalking & Sharding-Sphere
