There's no specific term. “Fork” is sufficient. “Soft fork” will be understood as well. “Branch” is another alternative.
In fact, forking is the expected behaviour when using a distributed version control system such as Git. Once you've published your changes on a fork, you can make a formal or informal pull request to have the changes from your fork merged into the upstream repository.
To projects that use centralized version control such as SVN, or to projects that are not familiar with this pluralistic, Bazaar-style approach to open source development, publishing a fork may be perceived as a bit more hostile. But as long as you are exercising your rights in the open-source license you received, you're going to be fine. Note that many of these licenses require you to
- clearly state your modifications from the original (though this might already be satisfied by the version control history)
- keep legal notices about the original.
All of that should not be a problem for a soft fork.
If you fork a GitHub project via their web interface, they will automatically mark your repository as a fork and link to the original.
In contrast to normal forking, a hostile fork is intended to compete, not collaborate. It has no intention of contributing changes back to the original project, and/or wants to enforce a change in project direction or leadership. A few well-known examples include OpenOffice→LibreOffice, MySQL→MariaDB, and temporarily node.js→io.js.