Hi

Good job, and @samz406 and @lilin put forward a suggestion earlier, I 
think it is very valuable. I quote here:



I think it can be explained in the pr description. If the newly developed 
function page is different from the previous one, you can simply provide a user 
manual to facilitate the user to get started quickly, or you can submit the 
user manual to the official website manual later.

????????????pr??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????




[1] https://lists.apache.org/thread.html/r2175e83e6d82be8d96dd9b476c6a99b91f6087050b5b01c9764966dd%40%3Cdev.dolphinscheduler.apache.org%3E







In my opinion, I think we can add the Commit Message template and example in 
`docs` and `Github PR commit message PlaceHolder` mentioned before [2]




[2] https://lists.apache.org/thread.html/r589b62b9cdb8ddcb875b6af8486101c99ff40524638b0d5e6b710ab3%40%3Cdev.dolphinscheduler.apache.org%3E







Best,

Yichao Yang








------------------ ???????? ------------------
??????:&nbsp;"CalvinKirs"<[email protected]&gt;;
????????:&nbsp;2020??7??8??(??????) ????7:45
??????:&nbsp;"dev"<[email protected]&gt;;

????:&nbsp;[DISCUSS] Build Commit Message RIP



The community's commit message currently has some problems


1. Many commit messages don't explicitly indicate what the code has modified, 
so we need to guess what it has done.


2. Some of the commit messages are associated with the issue on Github, while 
others are not, so it is difficult to trace the specific issue and pull request 
from a certain commit message.


3. The format of commit messages is not uniform.


We need some conventions to help the commit messages become clean and tidy, so 
as to help developers and release managers better track issues and clarify the 
optimization in the version iteration.


&nbsp;As Peter Hutterer puts it:&nbsp; "Any software project is a collaborative 
project. It has at least two developers, the original developer and the 
original developer a few weeks or months later when the train of thought has 
long left the station. This later self needs to reestablish the context of a 
particular piece of code each time a new bug occurs or a new feature needs to 
be implemented. "






So,I combined the specifications of RocketMQ and other communities , drafted 
the Chinese version of the CommitMessage of the DolphinScheduler community. For 
the link, see: 
https://github.com/apache/incubator-dolphinscheduler-website/pull/146


If you have good suggestions, please communicate with me, thank you




Best regards??
CalvinKirs

Reply via email to