Hi Oleg,
I am sorry if the change or the way I communicated about it is frustrating
to you . I'm happy to provide more insight into the motivation behind the
change, if that helps.
On Tue, Jul 24, 2018 at 12:41 AM Saint Johann <ole.yves(a)gmail.com> wrote:
— Some tell that, apparently, after working for 2
years already and
doing more edits than all sysops combined in JS/CSS, engineers do not
have ‘at least as much trust as being an administrator’ since they
weren’t elected like administrators (we are electing sysops with a vote
and engineers are being elected with a discussion, so people argue that
engineers do not have trust because they weren’t subjected to a vote).
I think someone who had those rights for a while and did not abuse them can
be reasonably trusted with them (which is why I suggested simple opt-in as
the migration process).
From what I could understood with Google Translate,
this seems to be the
current community consensus as well.
— Others claim that, because MediaWiki developer community decided to
unite those rights under one group, merging any groups
with it is not
acceptable, and, moreover, the engineer group shouldn't be given those
rights at all.
One goal with the change was to reduce the number of people with JS editing
permissions as much as possible without preventing them from doing their
work. If a group is primarily about JS editing, it might makes sense to
merge (that might be the case with interface-editor on some wikis, although
not all). If a group has a wider range of roles, then merging would mean
giving the permission to people who might not be interested in JS editing,
and avoiding that situation was the entire point. I 'm not sure which of
those applies to engineers - at a glance, out of the 12 of them 4 have
never edited CSS/JS and one almost never [1], so probably it makes sense to
separate interface-admins from engineers?
— Moreover, some people claim that if a group would be too small, like
engineers right now (12 accounts with 85 sysops), they
could, in opinion
of those people, usurp all editing of JS/CSS, decline to revert edits
that are deemed controversial by community, and this justifies giving
the permissions to all 85 existing sysops, even those that didn’t edit
JS/CSS at all.
Again, as far as I can understand the discussion this was a fringe opinion
and the current consensus proposal requires admins to opt in.
I really think that it all comes down to focusing on
projects that didn’t have any technical administrators
and not
explaining anything to projects that did.
For projects which do have some kind of non-admin JS editor role (engineer,
interface-editor, templateeditor, botadmin) there were two "social" goals:
- Warn them against handing out JS editor too easily. With the current
structure, that does happen sometimes, and can you get things like the
fawiki incident. JS editing should only be given to people who can be
trusted not to abuse their privileges to attack the site.
- Do not completely discourage people from handing it out to non-admins.
Trust is important, but it's a somewhat different kind of trust (admins
need to be socially competent, level-headed, fair etc; JS editors don't
really need to be all those things, they just need to not be malicious) and
there are people who can absolutely be trusted not to be malicious, but
don't have the social skills or the good judgement to be admins (or just
don't want be one), and there is no reason to prevent them from doing good
work on JS pages.
[1]
https://quarry.wmflabs.org/query/28510
Hope that helps!