Well, "documentation" may not be the most fun word for developers but it sure is needed when it's the middle of the night and you are still trying to figure out how to setup that library in your local. It makes sense to document a project setup, but not every detail may be worth documenting.

I came up with a list that helps me decide whether I should document or not:

Did I add a new library to the project? Follow-up question: does the library have to be in a specific version?

In this case, the source where the library should be downloaded from and the version are very important. It sure is worth writing down.

Did the project's language version just got upgraded and now are there more/less steps in the setup guide?

This one is a bit obvious but if the documentation is not maintained, these steps may be left behind. It's better to write it down now.

Do I think it would be nice for others to see example usages of the library I just downloaded or method I wrote?

Sometimes existing documentations of libraries may not be sufficient for your project or you have to use it in a different way. In these cases, it may come in handy to have examples in the documentation for others can learn as well.

Is my change affecting an API and its response/requests?

If yes, then document it!

Am I adding/changing an environment variable (or another important type of variable)?

This may affect the project in many ways. From the way it builds to runs, it's important everybody knows where they can find the guide to the most current and stable version of the project setup.

Depending on your project, the list can go on and on. Guides like these can be created in team meetings and could be very useful.

Do you agree with the points? How can we improve the list? Let's discuss!