+1 for that. Please add more information about the projects that could help other contributor to know better about the context of the JIRA and PR.
Willem Jiang Blog: http://willemjiang.blogspot.com (English) http://jnn.iteye.com (Chinese) Twitter: willemjiang Weibo: 姜宁willem On Tue, Jan 30, 2018 at 6:31 PM, Zheng Feng <zh.f...@gmail.com> wrote: > It could be helpful to have all of the changes in one commit for fixing the > issue of JIRA. And we can revert it easier in the future for the > regression. > Also including the link of the JIRA in the PR description looks better for > reviewing. > > 2018-01-30 18:09 GMT+08:00 郑扬勇 <yangyong.zh...@qq.com>: > > > Oh.. seems can do more better on first one :( > > Thanks a lot > > > > > > ------------------ 原始邮件 ------------------ > > 发件人: "Yang Bo";<oaky...@gmail.com>; > > 发送时间: 2018年1月30日(星期二) 下午3:15 > > 收件人: "dev"<dev@servicecomb.apache.org>; > > > > 主题: [TO ALL, Please read] Issues regarding commit messages and PR > messages > > > > > > > > Hi, > > > > I've been preparing the release notes for Servicecomb lately, and I have > > found the following problems: > > > > 1. The commit messages are not clear > > The commit messages should have a concise and clear headline describing > > what the commit changed followed by a detailed body explaining why and > how, > > and other necessary information. Most of the commit messages are unclear > > and does not have a body. > > Please read this article for how to write a commit message: > > https://chris.beams.io/posts/git-commit/ > > > > 2. The PR messages are not clear > > There is a rule in checklist for the PR states 'Each commit in the pull > > request should have a meaningful subject line and body'. But few of us > > followed. > > For simple changes, the commit message is enough to be used as PR > > message. For more complicated changes, we should provide more > information. > > > > 3. The issues in the Jira system are not clear. > > > > 4. The issue tags are not correctly used in jira. > > Changes that introduce new functionality can be tagged as feature. > > Changes only affect internal API should be marked as improvement. > > > > For tasks, we should also mark it as one of the following: > > feature/improvement/bugfix. > > > > > > Clear commit messages and PR messages is a critical part of an > open-source > > project. Because only with a clear history log, new developers can get > the > > information they are interested in without repeated direct communication > > with us. > > > > > > > > -- > > Best Regards, > > Yang. > > >