Hi, I propose some constructive ideas to improve the deployment of new features: * granular deployments: create "user profiles" where the users can choose if they want an overall appearance: * "never ever change my interface": some experienced authors do not like when one change every month their workflow if they are happy with it, * "experienced editor": some experienced editors want new features or see what the newbies see, * "newbie": the newbies/editors-to-be could expect an editing environment possibly different than the reader environment, * "reader": the readers have their own expectations for easy reading, * etc. The features could be deployed only for some groups, giving more flexibility to deploy "reader features" for readers, etc. Obviously there are preferences, but the newbies have no experience about it, and the experienced editors have to be discover new preferences on a case-by-case basis, making it difficult to everybody to track the preferences. * implement global preferences (and the possibility to change locally or globally, like in Mailman) [bug 14950][] * when a new feature is introduced, propose to users (not in "never ever change my interface") if they want the new feature, locally or globally, possibly using the Notifications bar, or with some message in the prefs page and highlighting it on the prefs page * work on a better organisation of the preferences, e.g. add an exhaustive preference panel similarly to Firefox’s about:config to permit the developers to add more preferences and hence offering more customisation possibilities for advanced users, by nullifying the argument "the preferences page is too complicated for new users" * as it was proposed, add a review process for the gadgets+JS pages to avoid performance, security, usability issues, possibly with the help of the tech staff, and possibly with the general MediaWiki code review (gerrit/Phabricator) with some gateway between it and the MediaWiki websites [bug 69445][] [bug 20153][] In other words, improve the deployment targets and give easy choices to users to opt-in/opt-out/etc the new features depending on their willingness to change their environment. And although I’m neither a loudly people neither the community, I vote to remove the superprotect right and any other enforcement of this type in the future. It’s like an edit war where one party has the power to silence the other, and like all edit wars there are at least two wrong versions. [bug 69445]: https://bugzilla.wikimedia.org/show_bug.cgi?id=69445 [bug 14950]: https://bugzilla.wikimedia.org/show_bug.cgi?id=14950 [bug 20153]: https://bugzilla.wikimedia.org/show_bug.cgi?id=20153 ~ Seb35