📝 add pointers on presentation materials

feedback.md

@@ -11,6 +11,9 @@ Online and in person at TC39 meetings, we're always giving feedback on proposals
   - Lack of desirability from one perspective, does not cause a problem on its own. Try to concretely explain how the problem impacts the usability of the proposal itself or of other parts of the language. Keeping feedback actionable allows discussion on how to improve desirability and cohesion for the whole language.
   - Try to phrase any feedback of constraints such that they are actionable rather than preventing some specific design choice. Explain the concrete problem that is being caused by that choice rather than why a proposal should not make a specific choice of design. Presenting problems in terms of concrete impact is more likely to allow champions to directly address if they agree that something needs action.
   - Discussing alternatives is encouraged, but please be flexible, especially on superficial issues ("bikeshedding"). Naming things is hard—it may require significant (or even insurmountable) effort to investigate each potential alternative, or there may be other constraints which are not immediately apparent. Ultimately, even if it is impossible to find a single uncontroversial name, we still all benefit by moving forward on a concrete choice. An explanation of the problems you're facing and how the alternatives relate to them is more valuable than vocal support for one or the other alternatives.
+  - Agenda presentation materials are provided to the committee in advance to facilitate informed and considered discussion in meetings. Avoid publicly redistributing or critiquing presentation materials before they've been presented in committee, allowing authors the opportunity to introduce and explain their work first.
+  - When giving public feedback outside of TC39 channels, engage directly with proposal authors first to ensure your input is well-informed and constructive.
+  - Always seek permission from proposal authors before copying, modifying, or posting any presentation materials. Simply linking to the original material is fine.
 - When you don't understand the motivation for a part of a proposal, one good strategy is to ask a question about it, rather than assuming that it's poorly designed.
   - Anchoring your probing questions in terms of problems to be solved can help to provide motivational clarity either for yourself or the original author (or both!) Clarifications in the past have included examples of the problem space in other languages, diving deeper into the performance impact of a proposal, or discussing consistency with existing semantics within the language, though this is not an inclusive list.
   - Understand that the language is used in such a wide variety of contexts that one's own distaste for a proposal isn't enough to warrant valuable feedback. Understand how the proposal benefits others before contributing, and keep feedback about motivation around the proposal itself rather than personal desirability or usage.