Hi,
this procedure is called “baselining”: Trying to find out which kind of findings an IDS/IPS produces, and which of them are false positives. Especially in production networks or enterprises, rules are always enabled step-by-step, watching the logs closely afterwards. Even large companies with a dedicated IDS/IPS team needs weeks if not months to conduct a proper baselining, especially if network documentation is poor.
Some of the rulesets are easy: You never want to connect to known C&C servers or hostile networks, no matter what. These can be enabled first, and usually do not cause any headache in terms of false positives. (The real headache comes with the true positives… 
)
Afterwards, rules are commonly enabled by priority: For example, if an IDS/IPS shields client networks, it usually makes more sense to take a look at rulesets like emerging-web_client.rules first. Should you are dealing with server networks, protocol-specific rulesets such as emerging-web_specific_apps.rules might be more important.
Then, there are some rulesets that you want to have enabled in almost any circumstances, such as emerging-malware.rules, emerging-exploit.rules or emerging-attack_response.rules - unless some of these cause too many false positives for certain applications or devices.
So, in the end, binging an IPS into production is an individual procedure, and general advice is usually sketchy. Being patient helps, and enabling things one by one - if you can overlook your network, you usually have some kind of feeling of what’s normal inside it and what’s not.
I have not stumbled across anything that explains the Rulesets.
For Emerging Threats, this and this page provide some, but not a complete explanation.
Hope this answer was helpful.
Thanks, and best regards,
Peter Müller