The answer that you linked to spoke specifically about seemingly inactive open source projects, not necessarily those that are active. I'm going to take the perspective if this were an inactive project.
The answer that you had linked has many useful guidelines. I personally like that answer: it provides many concrete points that you should understand when finding an inactive project.
I was wondering if there are any rules or guidelines when to fork a project and when to create a new one.
There aren't really any "rules" when forking an open source project. All that you really need to do is make sure that you respect the terms and conditions from the original license.
As long as you follow the license, you're in good hands. You won't get into any legal troubles or anything.
So what about guidelines?
Your quoted guidelines are really just steps, to form a single general guideline. If that's still confusing, think about baking cookies. First, you get the ingredients. Then you mix them. And then you put it into the oven. Same idea here.
Create a new repository.
If you find an inactive project, don't fork it. Forking on GitHub was more designed with the idea that you would submit a pull request - that is, that you would make improvements, and submit them back to the original project. Since you're not doing it, there's no need to "fork" it, as you will link to the original project, and you're contributions won't be measured on GitHub. By "forking", you give people the impression that this is for yourself, and you are intending to push it back to the original project. You are now maintaining the project, and you have full ownership of it.
Copy the original project into your new repository.
This is when you get all the contents from the original project, and you put them into your new project. Pretty simple, eh?
How does the license affect me?
I'm adding this part because it will likely be helpful, and of interest to you.
If the license is a permissive license, then you don't need to worry as much. These licenses give you many freedoms for your project, including assigning the project a different license. Some notable examples include the MIT and the Apache licenses.
If the license is a copyleft license, then you're going to have to keep your project under the original license. Some notable examples include the GNU General Public License, and the Mozilla Public License.