This is about language, language is evolving and is not used everywhere the same.
Cloning a repository in order to submit a patch sure enough creates another copy of the project, and there are some changes not yet found in a released version of the project whose code you cloned - yet that does not constitute a fork in the classical sense. Copies made and edited in order to submit patches and changes are just that: branches or different versions of the very same project.
A fork in the usual or original sense is a project which took a specific version of a project and developed it independently. Thus at a later point in time, they share a common history up to a certain revision, but then the code diverged. The cause for the creation of a fork often are differences in the governance of a project (e.g. LibreOffice was forked from OpenOffice, or Jenkins from Hudson). For these cases the projects diverge often increasingly so that after a certain time the exchange of patches becomes increasingly more cumbersome.
More generally a fork often is created when the direction a project takes with including or not including certain features. These forks with a slightly different code base are somewhat common for most major projects as not everyone can agree on every feature or omission - yet exactly this is the beauty of open source: you can and are allowed to fork it and create your own versions.
Thus depending on how permanent this separation is perceived, one might call these modified versions with some additional features, or patches or left-out patches not forks, but just "version" or "branches". A typical example for such a long- or medium-term lived version would be an project which rejected a suggested implementation of a much-asked-for feature which did not meet its quality or other guidelines for inclusion - but which is maintained by one or some interested individuals, but not diverging much beyond maintaining this feature branch. Call it fork, call it feature-branch - it's the same, just with a slight different take on the relation between the core developers and the ones of that feature branch.