Talk:Wikimedia Product Guidance/Community involvement

Dev involvement, community patches, collaborative design
Stray thoughts that I missed here + might be incorporated:

Consultations are not the same as collaborative design. If a consult looks like hundreds of duplicative inputs, that are never refactored or curated into something more, w/ an all-staff group is asking questions and a no-staff group giving all the answers, that's probably not collaborative design :)  Better for a design group to work in public, developing & prioritizing questions, and then answering them together, including answering one another.  Better again if the design product/design includes both staff and non-staff contributors.

Code review and attention to community code contribs: A really good collab will have community devs with review capabilities and commitment to fast turnaround for patch submissions.

Attributing motivation: if the motivation + idea comes from a community request, or a particular project or program that needs the work, attribute that and honor the time taken to formulate the original need + turn it into a spec. If it comes from research or observations or staff interest or a top-down mandate (legal? spiritual?) from someone not in either community or development teams, note that too. If a product is hoping to replace and subsume an existing workflow or product with different features or maintenance requirements, note that and how this affects people maintaining what existed before.

Being involved with + responsible for downstream impacts: how does this change documentation, existing outreach and work? Who updates those things, how is that coordinated with something new being announced to the world? Sj (talk) 20:17, 24 January 2023 (UTC)