There are few best-practices; there are some methods people have chosen for consistency in model development. I don't think documentation is the solution.
Working with parametric modeling is very similar to software development. The biggest difference is that software development is known to be a cooperative endeavor for anything but tiny projects. It entails code reviews, comments, other people understanding what was written and why it's that way, at least ideally.
In parametric modeling the same factors are still in place, but the discipline often isn't. Users often treat the part they are working on as somehow separate. I've had users feel it's too difficult to redefine a sketch for a feature and just delete it, replacing it with another feature - and thereby destroy multiple levels of assemblies and drawings, because they don't get how the interrelation that allows parts to accurately fit together has anything to do with their work.
To extend AD's response: The only way for consistent practices to work is to start with one user responsible for all the models - that is, they get to say if the models are acceptable or not, and if not, either they fix them or the person who made the model gets to redo the work. As a number of vetted works builds up, users will see more examples of what's done right, or at least what is consistent usage. Eventually it will become the norm.
The selection of that person is a critical one. It has to be someone who is capable of understanding what the models are supposed to do, be able to accomplish that within the limitations of the software, and be able to justify why their method is enough better or more useful to make the change. It is very helpful if they know how to easily teach others all of these.
The critical part is that management has to be willing to sanction users who won't or can't get the hang of it or absorb the cost of re-working the material, and also be willing to understand the risk that their go-to guy is the wrong guy for the job and work on making sure the management evaluation of that user is a useful one.
Before adding policies and prodedures, start by reviewing a few hundred models and drawings. Collect the concepts that seem to work, including down-stream CAM and other efforts. Look at those concepts that are painful and understand the circumstance that led to that. Example: the revolved cuts. It's a single feature that can be redefined to be a c'bore, or with countersinks on one or both sides, or include a snap-ring groove, at any time while losing the least info when redefined. Perhaps it was done before hole features worked - they used to really stink big time. Knowing why a feature is used in a seemingly odd way will go a long way to developing a consistency.
You might consider ModelCheck as well to weed out some of the more interesting methods of forcing invisibility on parts and features that few others would think to use. Like creating a feature to fill or completely remove another feature. Or using simplified reps to control assembly configurations so that the assemblies can't be found in Windchill. Which reminds me of a great trick. Doing a save-as on a drawing of one part, removing all the views from the copy, but not the models, and adding a different part. I've seen this done where a bracket is placed on a drawing of a complex assembly. Nothing like expecting two items in a workspace and getting a few hundred. Good times.
Here's one I consider to be a good practice - create the location dimensioning scaffold before creating feature driving geometry. For example, on an extruded hole I'll use construction lines aligned to part edges and crossing where the hole will be and create dimensions to them; not to part geometry or to sketched curves directly. Then sketch the circle at the intersection. Why? If/when the decision comes to make it a slot, nothing else is affected but the outline. The locating dimensions shown on the drawing, with all their settings, will be unchanged. If I copy the sketch, all the dimensions come with it and merely need to align to a new location. If I'm really after some permanence, I'll include a sketched axis point that has a dimension that can move it off center. This way even when converting from circle to slot, mating hardware aligned to that axis won't be affected -and- if changed to a slot, I can move it independently and see the effect in using assemblies. Circular hole to straight slot to curved slot and next assemblies work fine.
All of which is a bad practice if designs never change from circlular holes to slots and no one is ever concerned that hardware may move off center during assembly.
