[Feature] Add PR and issue specification documents

[caicancai]

The specifications of issue and PR are the standards that a good community should have. We should explain these specifications to developers. This is conducive to community archiving and developers to learn. I don’t know if such a document already exists.

[caicancai]

I have seen some communities leaving some historical artifacts due to irregularities in submitting pull requests and issues. I hope fury can avoid this, even if it may discourage some developers. I want to hear your opinions.
cc @chaokunyang @PragmaTwice @theweipeng

[chaokunyang]

Hi @caicancai, thanks for bring up this. Could you share some project which have a good pr/issue document?
Currently, we do need some updates.
One method I can think of is to update our PR/issue template

[caicancai]

If we update your PR/issue template, will it address this?

No, to completely solve this problem may require one-to-one communication between the memeber and the developer's PR, but this is unfair to the memeber. We can reduce this problem through documents + update your PR/issue template, etc. The occurrence of similar problems, such as adding a check on the PR title in the cli and updating your PR/issue template, etc. This method is very common in some communities. I know that the calcite community is currently more strict about this, but I feel that the calcite community is too strict.

[caicancai]

My current thoughts are

1. update our PR/issue template
2. Add check for pr title in cli
3. Add this part of the documentation

This is just my opinion, I'm sorry if it offended

[caicancai]

@chaokunyang I looked at other projects like calcite, spark, etc. I think it is a good choice to add a PR title check in cli. For example, restrict PR to have keywords: issue number, hotfix, etc. The standards we need to specify are which PRs should be issued and which ones are hotfixes.
There are not many developers at present, so this responsibility can be temporarily completed by memeber, but for long-term development, I think it is necessary to add this cli check.
This work may be a long-term process

[PragmaTwice]

For PR titles, we can follow the conventional commits.

IMHO designing PR and issue templates is quite challenging. Additionally, I believe that excessive restrictions are not beneficial.

[caicancai]

For PR titles, we can follow the conventional commits.

IMHO designing PR and issue templates is quite challenging. Additionally, I believe that excessive restrictions are not beneficial.

Thank you for your reply. Yes, how to ensure that there are no excessive restrictions is also a complex issue. Some communities are trying a very strict restriction, and the shortcomings are also very obvious, which may discourage some developers. We should probably think about how to grasp this degree. If we want the community to develop healthily, I think this is indispensable.

[eolivelli]

Hello,
In my experience it is usually enough to have a good pr/issues template.

We could enforce the PR title to some specific format.

You check it out in apache/pulsar

@tisonkun worked on this topics for the Pulsar community

[caicancai]

thank everyone #1317