Topic on Talk:Technical Collaboration Guidance/Community decisions

The guideline "Foundation Product teams should, as early as possible in the project timeline, share information about projects with the community" perpetuates the old one-way view of engagement with the Community. I suggest that this should read something like

• Formal project proposals made by Foundation Product teams should be accompanied by a description of the case for development. This should, and in the case of project that signficantly add to or change community workflows, must include a clear demonstration of community engagement and disussion of potential benefits and costs for the community.
• Project proposals must be ina friednly tone, use constructive arguments, data, actionable alternatives (one of which must always be do nothing') with a clear analysis.
• Demonstration of community engagement must include evidence of consensus when claiming to represent the view of a community or a large section thereof.
• Prior discussions and agreements within the community need to be taken into account. There must be good reasons to reopen a settled topic.

Of course some of these bullet points are reminisicent of the requirements for community blockers. And why would they not be?

Good points. Yes, development teams should share information when projects are still proposals open to discussion, and they should be subject to the high expectations about the quality of their communications.

I have edited the draft in order to reflect this idea better. To avoid duplicity, I have linked to other recommendations defining when to communicate new proposals and how. There might be a point in trying to make this more modular, setting common expectations for proposals and blockers. For now I have just aimed to link better the different recommendations.