Group classes together in a same package that relate to the same abstraction. All User related classes should go in the user package.
Group classes together in a same package that are likely to change together. If a class imports lots of classes from another package, maybe it should be in that package - minimising imports is a useful heuristic in deciding where a class should go.
Minimise the number of 'visible' classes in a package. In the way that an object will expose an interface (public methods) but have many more internal ones (private methods), a package should have only one or a few classes that a client will ever have to interact with. Make the constructors / factory methods on the internal only classes 'protected' or 'private' to document this.
Do not allow cycles in the package dependency graph. For example A -> B -> C -> A is not allowed.
To break these cycles we can add a new package, to give us A -> D, A -> B -> C -> D
A better solution is to use the DependencyInversionPrinciple and extract an interface.
Depend in the direction of stability. Depend upon packages whose Package Instability (see MetricsPage) is lower than yours.