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
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
