Talk:Strategy/Wikimedia movement/2018-20/Working Groups/Product & Technology/Recommendations/4
I believe it is important to change:
"between the organization building the feature and the editor community."
"between the organization building the feature and the editor and reader communities."
- I'm not sure that's feasible (nor that it solves a problem that exists). Having a single group represent all the wiki communities is challenging enough, but there at least the individual wikis have well-defined power and communication structures to build on. How would we select reader representatives? To whom would they be accountable? How would they know what readers want? --Tgr (talk) 11:07, 15 August 2019 (UTC)
- Yes, more detail is needed. How much of this decision making body will be chosen by the volunteer community? Who will appoint them? Until I know the answers to these questions, I cannot support. MER-C (talk) 16:48, 11 August 2019 (UTC)
How is this different from a https://en.wikipedia.org/wiki/Change-advisory_board ? Siebrand (talk) 21:22, 11 August 2019 (UTC)
- I'm not sure it is different, CAB is a pretty generic concept. Personally I find political metaphors more apt for the Wikimedia movement than Big Tech ones, hence the name. --Tgr (talk) 11:07, 15 August 2019 (UTC)
Relationship to recommendation 3
I see this as being highly coupled with the recommendation to open up product governance to the point where I can't see one succeeding without the other. Specifically, this deployment council seems necessary to ensure that product council decisions are accepted by the communities they represent. TNegrin (WMF) (talk) 00:50, 3 September 2019 (UTC)
@TNegrin (WMF): Yes, the recommendations on deployment council, discussion platform and tech evangelism (a somewhat misleading name, we changed it to the drab but more accurate knowledge dissemination) are all envisioned as supporting recommendations for open product proposals, which is one of the big overarching changes we recommend. I mainly see it as bridging the gap between committing to a product plan and accepting the changes to that product plan that happen during development (which often can neither be predicted nor avoided, and keeping the open decisionmaking process running during the whole development phase is not sustainable). --Tgr (talk) 20:02, 8 September 2019 (UTC)
From Catalan Salon
Software deployments have been a repeated point of clashes, and along with #3 this seems like a good and fair way to try and address that. I support this recommendation. A few related thoughts:
- Deployment isn't necessarily a binary status of deployed/not deployed. There are features deployed to only some wikis, Beta Features, A/B tests, all of which can be valuable in the development process. There will need to be some thought over which stages require Deployment Council input/approval.
- Would this process incorporate other existing deployment requirements such as Security review, Design review? Or would this solely be about the community side?