Thanks for all of the comments.
Based on some of them, I apparently was not sufficiently clear.
There are potentially three discrete steps to reaching the point where CPWG recommends a comment to the ALAC.
1. The people who volunteer need to be up to speed on the subject. In an ideal world, that should already be the case with at least some of the volunteers and hopefully the lead ones. In some cases, reading the documents presented with the comment may provide the needed background. In other cases, they may not suffice.
2. In preparation for presenting a potential comment, the CPWG may need to be briefed on the subject CPWG participants can make informed decisions on the comments being discussed. Understanding the impact on users is part of this, as that may be a consideration in deciding whether a comment is warranted. The briefing aspects of this step can be done by the comment volunteers, staff, or other At-Large participants.
3. If a comment is warranted, it needs to be drafted, and then discussed within the CPWG to finalize it. Currently there is a process by which the proposed comment is first discussed in bullet-mode form. This may or may not be warranted based on the complexity of the issue, but it is good practice if the time-line allows.
My original concern is that the presentation of item 2 to the CPWG seems to be melded into the drafting of the comment. The comment itself is targetted at some other group in ICANN who do not need the background nor the user-impact analysis. Aspects of the user impact or the background leading to the comment MAY be necessary in the comment if understanding those is critical to explaining why the comment should be adopted by the target team. But in general, all of 2 is background for the CPWG and not an integral part of the comment.
My concern is that producing long convoluted comments where the actual recommendations are unclear, or buried in extraneous text can only lead to our comments not being accepted and implemented.
Alan