Actually you’d be surprised we have quite a number of community contributors and it’s growing each month.
My concern is that adding these extra layers for the reviewer can make maintaining this project more tedious. As a maintainer for GitLab’s frontend code, I would highly recommend automating some of these things as it is easy to get a lot of PRs to review once the community picks up because majority contributors tend to miss these smaller details when contributing PRs. On Wed, Sep 4, 2019 at 9:15 PM Ovilia <oviliazh...@gmail.com> wrote: > Hi Clement, > > Thanks for sharing information with us. > I suppose most of the committers in your projects at gitlab are all > employees so that there won't be a problem with frustrating community > contributors with compulsory changes when CI fails. > But this could be a problem for us, especially when we wish to encourage > more people to contribute. > > So I'd suggest our committers follow the guidelines, and make this > guideline informed to the community but do nothing compulsorily. We can > change the commit message when merging the PR in. > > Wenli > > > On Thu, Sep 5, 2019 at 8:48 AM Clement Ho <clem...@gitlab.com.invalid> > wrote: > > > We use danger bot at gitlab. It comments on the MR/PR and also fails the > > pipeline when something about the MR/PR is incomplete/incorrect > > > > On Tue, Sep 3, 2019 at 10:05 PM Ovilia <oviliazh...@gmail.com> wrote: > > > > > Hi Clement, > > > > > > What's the process if we add this in CI? > > > > > > I was considering making these guidelines not compulsory for the > > community > > > to avoid the roundtrips as you mentioned, and the commit message can be > > > updated by who approved the pull request in the squashing stage. > > > > > > Wenli > > > > > > > > > On Wed, Sep 4, 2019 at 8:45 AM Clement Ho <clem...@gitlab.com.invalid> > > > wrote: > > > > > > > I'm also concerned that this may create more roundtrips during code > > > reviews > > > > from the community (if we don't automate parts of it) > > > > > > > > On Tue, Sep 3, 2019 at 7:43 PM Willem Jiang <willem.ji...@gmail.com> > > > > wrote: > > > > > > > > > I think providing the fix issue id is quite important for the > others > > > > > who want to dig the code. > > > > > The issue id could link to the discussion or some doc explain why > we > > > > > do this kind of change. > > > > > It's good practice to share the development context across the > > > community. > > > > > > > > > > It could be a pain for the first contributor to submit his first > PR, > > > > > but with the guide document will reduce that pain. > > > > > > > > > > Just my 2 cents. > > > > > > > > > > Willem Jiang > > > > > > > > > > Twitter: willemjiang > > > > > Weibo: 姜宁willem > > > > > > > > > > On Wed, Sep 4, 2019 at 6:40 AM Sheng Wu <wu.sheng.841...@gmail.com > > > > > > wrote: > > > > > > > > > > > > Hi > > > > > > > > > > > > This kind of requirement should come from a high diversity and > very > > > > > active > > > > > > community, like the example your using. > > > > > > The only reason the commit log important, is because of quick > > review > > > > > update > > > > > > and revert in some critical case. > > > > > > > > > > > > From the commit log today, there is not that case. > > > > > > https://github.com/apache/incubator-echarts/commits/master > > > > > > > > > > > > I am supporting commit id as better as possible, but also, PPMC > > > please > > > > > > consider Justin's question/concern, don't make a higher bar than > > > > before. > > > > > > > > > > > > Sheng Wu 吴晟 > > > > > > > > > > > > Apache SkyWalking, Apache ShardingSphere(Incubating), Zipkin > > > > > > Twitter, wusheng1108 > > > > > > > > > > > > > > > > > > Justin Mclean <jmcl...@apache.org> 于2019年9月3日周二 下午3:34写道： > > > > > > > > > > > > > Hi, > > > > > > > Just out of interest what is the problem you're trying to solve > > > here? > > > > > It > > > > > > > seem to me that doing something like this will make it harder > for > > > > > users to > > > > > > > contribute, when you want to make it easier for them to do so. > > > > > > > Thanks, > > > > > > > Justin > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@echarts.apache.org > > > > > > > For additional commands, e-mail: dev-h...@echarts.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@echarts.apache.org > > > > > For additional commands, e-mail: dev-h...@echarts.apache.org > > > > > > > > > > > > > > > > > > > >
