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

Wikimedia-l mailing list, guidelines at: 
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Reply via email to