Let me outline a procedure, which I think would save a lot of people a lot of trouble.
First, instead of using the term "package" let's use the term "application". A package may always be considered to be part of an application but an application does not necessarily have to include a package. An application might be any group of folders and files associated with some subject that you want to keep together.
WRI has provided a standard place to put applications and that is in the $UserBaseDirectory/Applications folder. You can find the UserBaseDirectory by evaluating in a notebook:
$UserBaseDirectory
(My experience is that many people I communicate with will put their packages anywhere but there. They always have some reason but THAT IS THE BEST PLACE TO PUT A PACKAGE.) The reason that this is the best place is that Mathematica automatically looks there for not only packages but also palettes and style sheets, which will automatically appear in your menus. It will also look there for an init.m file that you might want to associate with that application. If you someday add documentation Mathematica will also find it. Secondly, it is part of your own personal files and will persist independent of Mathematica updates. Another advantage is that the application packages can be loaded in a uniform manner from any notebook in any location. If you want to make links to other notebooks associated with the application you know exactly where to look for them. You never have to get involved in setting directories. If you want to send the entire application to someone else you can just zip it up, send it to her and she only has to unzip it into her $UserBaseDirectory/Application folder. Those are all significant advantages. Even if you are starting out with a modest application, say with just a package, that is still the best place because you can easily expand it later into a more elaborate application.
So your file structure might look something like the following (where I am showing how various optional elements might be included):
$UserBaseDirectory/Applications/
ProjectX/ (* top folder for the application *)
Documentation (* any documentation you might later add via Workbench *)
FrontEnd/
Palettes/ any palettes
StyleSheets/ any style sheets
Kernel/ init.m
package1.m
package2.m
MyTutorials/ perfected notebooks associated with ProjectX
DevelopmentNotebooks/ ...
SallysNotebooks/ notebooks done by an associate.
But you might start out with just the top folder, the package and maybe a working folder for notebooks associated with the project.
The BeginPackage statements for your packages would look like:
BeginPackage["ProjectX`package1`",{...}]
Notice that the path from the Application folder is included in the package name here. ProjectX is part of the Context. Then a user could, from anywhere, load one of the packages with, say:
<<ProjectX`package1`
But a much better method is to write an init.m file that looks like this:
<<ProjectX`package1`
<<ProjectX`package2`
Then WRI has implemented a neat shortcut such that the entire application can be loaded with:
<<ProjectX`
When Mathematica sees only a top level folder in the Get statement it automatically looks for the init.m file in the application and evaluates it.
So when you think package, think application instead and, if you get off on the right foot, things will go much smoother from that point on.
