Quoting MZMcBride: "...the two issues (a rush to deploy features versus resource allocation for unwanted features), while sometimes intertwined, can certainly also be discrete." I agree with you in this point, and the Technical Committee is intended in part to improve both situations. Quoting David: "Unfortunately - and we quite definitely saw this in the VE introduction - it leaves a lot of them in the position of customer service ablative firewall, the designated targets of people's frustration." Yes, and this is unfortunate. I sometimes feel that the Community Advocacy and Engineering Community Liaison groups get blame for decisions that were made by other people, and these liaisons are placed in the difficult position of trying to please everyone. I have sympathy for the people in those roles and I feel that they often do good work for the WMF and the community. Quim, it seems to me that the methods used by Features have repeatedly produced troubled results over the years, so it's time for a different approach. Grantmaking has a community-intensive approach to making major decisions and I think the same approach should be taken in Features. I am optimistic that embedding the community deeply in leading Features would be a long-term change for the better. I believe that the Tech Ambassadors aren't empowered to make high-level community recommendations about Features as the Technical Committee is intended to do, although Tech Ambassadors may want to volunteer to serve on the Technical Committee and/or be integrated into its work. I would like to invite you and the Tech Ambassadors to participate in the discussion about the Technical Committee on the Board Noticeboard [1]. Pine [1] https://meta.wikimedia.org/wiki/Board_noticeboard