Communication plans or communication activities should only be included in a work breakdown structure if they are the deliverables. Even in such cases, the breakdown should reflect steps in the project rather than daily calendar items of interest only to the task performer.
Define Your Level of Granularity
Your question is not directly answerable because the granularity of the milestones you're breaking down is not well-defined. In common usage, a work breakdown structure is essentially a list of discrete tasks that directly relate to a deliverable or milestone. Some of your communication items don't appear to fit into that category, but it's certainly possible that (in the abstract) some communication tasks might.
The art of creating a work breakdown structure comes from understanding what level of granularity is required, and whether the goal is to communicate about things people need to do or about estimated hours needed to do those things. I generally use a WBS for the former, and use other mechanisms to radiate information about the latter.
Part of good project management is having an effective communications plan. However, it is rare to see the communications plan as part of the work breakdown structure--not so much because it can't be, but because the purpose of the WBS is primarly a task analysis tool.
Your Specific Communication Items
You list the following three items:
- Discuss risk management with manager
- Ask for orders of new network equipment
- Call support agent for overtime costs
All three items seem outside the scope of a WBS because they seem like they each fall below a useful level of granularity for the project. The task performer certainly need to track those individual tasks, but the utility of breaking down "order new equipment" into "ask my boss for permission to call Bob in accounting for the paperwork to send to Alice in purchasing" seems unnecessarily detailed at the project level. Your mileage may definitely vary, though.
In addition, setting aside time in the project plan for risk analysis or risk mitigation is certainly useful, and belongs somewhere in the project plan. However, while WBS items belong in the project plan, a project plan is not simply the sum of WBS items. Semantically, scheduling a discussion is neither a work product nor a useful decomposition of risk management; I'd recommend using a different mechanism for risk management, such as:
- A risk management log.
- Adding a risk assessment phase to your project plan.
- Building risk management into your entire process, rather than having a one-off procedure for it.
The specifics of how you control risk will depend a lot on your project and your organization. Those controls should be part of your time or effort estimates, but (in most cases) probably not your assessment of the steps needed to perform a given task like running cables. Again, your mileage may vary.
Resources and References
As defined on Wikipedia, the following WBS design principles argue against including your communication items in the work breakdown structure:
Based on these principles, and for the reasons I described above, your communications items don't belong within the WBS. However, you should definitely radiate information and provide project status. Such activities belong in your project plan; just not in a work breakdown structure.