Improve pull_request_template.md

[wolfogre]

Update pull_request_template.md because:

• It's a kind idea to hide the tips. However, it's easier to include them in the commit message by mistake when you cannot see them. Check git log | grep 'Please check the following:'. So don't hide it, expose it and help fix it.
• "for backports" is much clearer than "for bug fixes". I saw someone post a PR to a release branch because they believed it was the right way for a bugfix.
• "Allow edits by maintainers", or we have to ask the contributor to update the branch and they could be confused.
• Remind the contributor that the words could be included in the commit message, to avoid some words like "Hello", "Sorry". If they really need them, they can separate them with a line, like:

Close #xxxx
Because ... Then ... Finally ...
---
Hello, this is my first time opening a pull request. Sorry for any mistakes.

And the merger should be careful, check and delete the extra content before merging.

[yardenshoham]

I don't really like that --- rule. I'd prefer that info in the first PR comment.

[wolfogre]

I don't really like that --- rule. I'd prefer that info in the first PR comment.

Why not?

If contributors don't like it, they don't have to use it, and they can still write things in the first comment.

If mergers don't like it, it's probably because it requires them to merge more carefully. And that is indeed my evil plan!😂

Just kidding, I'll update it to "the first comment" if most people don't like ---.

[yardenshoham]

If you do keep the --- change (which, again, I am against). You'll have to make changes in at least one other place,

gitea/CONTRIBUTING.md

Line 266 in 7b5b739

with the rest of the summary matching the original PR. Similarly for frontports

The backports today take the original PR's summary

[wolfogre]

If you do keep the --- change (which, again, I am against). You'll have to make changes in at least one other place,

gitea/CONTRIBUTING.md

Line 266 in 7b5b739

with the rest of the summary matching the original PR. Similarly for frontports

The backports today take the original PR's summary

I haven't thought about it, because I always send backports like git cherry-pick [the commit id which has been merged to main], and the commit message (I believe it has been corrected) will be the body of new PR automatically, and the only thing I have to do is just add "Backport #xxx".

I don't know, maybe I'm not doing it the usual way. Whatever, if it turns out that the merger needs to be more careful, I'm fine with that. Even without ---, the merger still has to check it again if the contributor keeps the deleted text in backport PR. However, if contributors know how to use --- in the right way, it will be easier to check.

Maybe we can have a robot to send backport PRs automatically, and it's easy to recognize --- and handle it. I heard you already did something like that. 👀

[yardenshoham]

When I did it I followed these instructions so when I create the PR I literally concatenate them:
https://github.com/yardenshoham/gitea-backporter/blob/5ebdca217f8b22c18951e0bef014d60a7bc7679c/src/github.ts#L80

[wolfogre]

When I did it I followed these instructions so when I create the PR I literally concatenate them: yardenshoham/gitea-backporter@5ebdca2/src/github.ts#L80

You are right to follow the instructions, however, if the merger has adjusted the commit message and your awesome backporter uses the originalPr.body to send a backport, the merger has to adjust it again. That's not your fault, that's the merger's work, if your backporter removes ---, that's a friendly help. If your backporter keeps it, it still does nothing wrong.

BTW, could you please add a delay to backporter? I mean just help sending backports only for PRs which have been forgotten for maybe 24 hours, to avoid conflicts. Never mind if you already did.😄

[wxiaoguang]

I agree with the "---" separator, or anything similar to help to distinguish commit-message and none-commit-message. It just helps the mergers to know which part is important while which part is not.

Mergers should always pay attention to the merge messages, and improve the message manually if necessary, instead of just clicking "Merge" without any check. Clicking "merge" without any check is the easiest work without any requirement, mergers should do far more than that. I have said many times in discord channel that the commit message was polluted, but various unrelated messages still go into git history.

[yardenshoham]

@wolfogre

No problem, I'll change my code to match whatever behavior is written in CONTRIBUTING.md but you have to agree that before this PR lands, there must be changes to CONTRIBUTING.md

Thanks for calling my backporter awesome!

[wolfogre]

... I'll change my code to match whatever behavior is written in CONTRIBUTING.md but you have to agree that before this PR lands, there must be changes to CONTRIBUTING.md

TBH, I don't really know how to update CONTRIBUTING.md, it's clear and correct to say "with the rest of the summary matching the original PR." It's the merger's job to remove the ---, not the backport sender. There's nothing wrong with keeping the --- in a backport PR.

[yardenshoham]

Again, why I think the first comment is better than --- 443dcc2