Hi, thanks for the suggestions~
> A pull request that changes many files should include many commits that descript the changing intention in order to make reviews easier. +1 for that. A pull request is supposed to describe the intention of it in description in detail. And of course, the commit message should express what you modified explicitly. > especially the issue title >From my perspective, if the issue title is written in both English and Chinese, it will be too long to show completely. So maybe only English is better. weizihan0110 <[email protected]> 于2020年12月30日周三 下午6:51写道： > +1, > Some other suggestions: > 1. A pull request that changes many files should include many commits that > descript the changing intention in order to make reviews easier. > > 2. Issue description should be both in Chinese and English, especially the > issue title. As issue title can be a navigator, people familiar with > English or Chinese can be led to that place and have a discussion. > > > | | > Al Wei > | > | > 邮箱：[email protected] > | > > 签名由 网易邮箱大师 定制 > > On 12/30/2020 16:22, Xiangwei Wei wrote: > Sorry guys, it seems that the email @dev can't show the pictures directly. > - -.. > > > The pictures are in the following link: > [1] > https://user-images.githubusercontent.com/34242296/103338924-eddd2e00-4aba-11eb-800f-f89cf052b268.png > [2] > https://user-images.githubusercontent.com/34242296/103338937-01889480-4abb-11eb-9850-4b41336d246e.png > [3] > https://user-images.githubusercontent.com/34242296/103338945-05b4b200-4abb-11eb-8153-7ea5de4fa224.png > [4] > https://user-images.githubusercontent.com/34242296/103338947-09483900-4abb-11eb-9a7a-aa163d01497f.png > [5] > https://user-images.githubusercontent.com/34242296/103338965-106f4700-4abb-11eb-851d-6571056b7164.png > > > or the all can be viewed in: > https://github.com/SteveYurongSu/iotdb/issues/1 > > > > Xiangwei Wei <[email protected]> 于2020年12月30日周三 下午4:12写道： > > Hi all, > > > Recently I found there are some problems existing in the commit process of > IoTDB and it's getting worse. > > > Let's see the actual situation directly. (The screenshots are just > examples, there is no offence.) > > > First, > > > It's necessary to create an issue and pull a request for each commit. > Maybe some commits are simple enough to ignore an issue, like doc > modification, but it's still important to pull a request and have a review. > We should try our best to avoid pushing to the repository directly. The > following is a good example: > > > > > > > Secondly, > We don't have enough information for each commit now. > > > Let's see the git log of HBase, thanks to the help of @Yuqi. :D > > > > > > > In each commit, > 1. the issue number > 2. the summarization of commit > 3. the PR number > 4. the PR reviewers are included. > It's a very standard process I think. It's great if we can use it for > reference. > > > The following are some bad examples of ours: > > > > > > > > > > > Since the contributors don't have write privilege, so all people who have > the privilege to merge pull requests should be aware of this. Be great, be > standard. > > > > > Thirdly, Do not force-push a commit if someone has reviewed your code. > It's a large workload to review a PR if it involves many files. And if you > force-push a commit, which means the reviewers have to check all modified > files again. Maybe you just want to reduce the number of your local > commits, but it's still not a good habit. > > > Fourthly, Use squash merge. > It's related to topic 3. Since each pull request may involve many commits > the author commits, it's better to squash it as one commit when merging it > into master. > > > > > We are a young project indeed. Let's make our efforts to make it better. > If you have any advice, please leave your opinion. :D > > > -- > > Best, > Xiangwei Wei > > > > > -- > > Best, > Xiangwei Wei -- Best, Xiangwei Wei
