Add Pull Request template

[nirarg]

I open this PR as suggestion and discussion about what should be our guidelines for Pull Requests

The purpose of this template is to provide the author with a clearer set of instructions on the necessary steps to follow in order to create a proper pull request. As a result, the review process will be streamlined and more effective.

[eloycoto]

I'm not sure if this helps at all, my experience is:

• At the moment, we don't even force good commits. So, IMHO, we're far away from writing good PR descriptions.
• The templates, in my experience, only help to have a placeholder that no one uses.

[masayag]

I'd merge this one with the above

[nirarg]

Done

[masayag]

s/Docs/Documentation

[nirarg]

Done

[masayag]

These two will be run by the CI, I don't think there is a need to check them manually

[nirarg]

But it can be good reminder for the Author, before the PR is opened

[masayag]

it is implied by **Impacted elements** section

[nirarg]

As I see it, **Impacted elements** indicates if the element code was changed (i.e. changed integration test)
But even if the integration code is not changed, it need to be validated

Any way, I'm flexible on this matter and it can be eliminated to simplify the template.

[nirarg]

Removed those lines

[nirarg]

I'm not sure if this helps at all, my experience is:

• At the moment, we don't even force good commits. So, IMHO, we're far away from writing good PR descriptions.
• The templates, in my experience, only help to have a placeholder that no one uses.

I think this is a good thing to start with
And this is our responsibility as a group to enforce this (if we think it may help)

[rgolangh]

I would take this and put it as the start of CONTRIBUTING.md and consider making this template bit more concise.
Doesn't have to be in this PR because it is a good improvement from what we have now.

[rgolangh]

I'm not sure if this helps at all, my experience is:

• At the moment, we don't even force good commits. So, IMHO, we're far away from writing good PR descriptions.
• The templates, in my experience, only help to have a placeholder that no one uses.

I think this is a good thing to start with And this is our responsibility as a group to enforce this (if we think it may help)

I'm not sure if this helps at all, my experience is:

• At the moment, we don't even force good commits. So, IMHO, we're far away from writing good PR descriptions.
• The templates, in my experience, only help to have a placeholder that no one uses.

I think this is a good thing to start with And this is our responsibility as a group to enforce this (if we think it may help)

in time if this is just a burden we can narrow this down

[rgolangh]

Here we can put "FLPATH-xxxx " as an example to what we expect

[nirarg]

Added

[rgolangh]

@nirarg since you suggested it and there's some debate around it - can you take revisit this with the team in say 2 weeks, 1 month from now?

[pkliczewski]

Here is an example how assisted installer team defined a template.

[pkliczewski]

/lgtm

[masayag]

/lgtm

not yet approving to allow others to add their comments.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

Approval requirements bypassed by manually added approval.

This pull-request has been approved by:

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment