Guidelines for writing better pull request description for features

As we know, the description written for the pull request is all you have got to explain. It also helps the reviewer while reviewing your Pull Request. Writing a description may take time, but it is essential. We recommend you follow this template while writing pull request descriptions.

---

TODO:

• Development.
• Test cases.
• Documentation (If required). description

The Todo/Status/State of your development helps the reviewer to start review. PR will be reviewed, when all to-do tasks are completed.

Settings (optional)

This is one line introduction (If required).

--screenshot--

This section of the description will contain the settings(like HR Settings, Stock Settings) created/changed. It is optional but put this section on top if you have defined any.

Masters Document Type

DocType 1

This is one line introduction (If required).

--screenshot--

DocType 2

This is one line introduction (If required).

--screenshot--

Master Document Type(DocType) is a BluePrint of Document linked to other Master or Transactional documents. Ex: Like Employee is a master DocType linked with other DocType like Attendance, Check-ins, etc.

Transactional Document Type

DocType 1

This is one line introduction (If required).

--screenshot--

DocType 2

This is one line introduction (If required).

--screenshot--

Transactional Document Type is a BluePrint of Document, which is used frequently like Attendance, Sales Invoice, etc.

Section 1 (If Required)

This is one line introduction (If required).

--screenshot--

Section 2 (If Required)

This is one line introduction (If required).

--screenshot--

You can add another section to showcase other developments like reports, dashboards, etc.

Workflow:

• Step 1
• Step 2
  • Step 2.1
  • Step 2.2
• Step 3

It will help the reviewer while testing the feature locally. He will be able to point out changes required in the workflow.

Validation: (optional)

Example:

• User having Interviewer Role will only be able to submit Interview Round, Interview, and Interview Feedback.

Most of the time, some invalid validation is missed by the reviewer. List all the validations done apart from the Standard one.

---

Advantages:

• Developer interaction reduced during code review.
• Better Description will help the testing team while testing the feature.
• Person from the community will also be able to understand the feature.

NOTE:

• Pull request only with better description will be reviewed.
• Always try to add as many screenshots as you can for a better review.
• Workflow and DocType(With screenshot) definition is mandatory.
• Always use Document Type in place of DocType, as per non-developer perspective.