merge-conflicts label

[nelsonic]

Ideally there would never be any merge conflicts in projects and everyone would be happy,
but sadly, quite often on larger projects (more than one pair of developers)
we get merge conflicts in Pull Requests.

what do people think about having a merge-conflicts label
for this so Reviewers/QA never has to (manually) write out:

"please resolve merge conflicts on this PR ..."

and everyone understands what it means when this label is applied to a PR...?

"DWYLBOT" 🤖 Automation Enhancement:

when an event happens on a pull request (e.g. new commit pushed or assignment changed etc.)
we should check all Open Pull requests on the repository for Merge Conflicts...

And based on the existence of merge conflicts:

• the merge-conflicts label should be applied and
• the PR should be assigned back to the person who created the PR.

[nelsonic]

haven't had any feedback on the wording for this label...
I know I'm *Not The Only One who is seeing the merge conflicts while QA-ing PRs on projects...
But maybe others haven't Felt The Pain of having to write the same comment a thousand time:

"Hi {Name}, Please fix the merge conflicts and re-assign (back to me) for review. thanks!"

So...
I'm creating the label as resolving-merge-conflicts so it's a "doing" state.

[iteles]

I personally am not as nice as you. If the build is failing or if there's a merge conflict, I assign the PR back to its creator without the niceties, so it doesn't 'cost' me much time.

It would be good to get thoughts on this from our QAs.