Change 574636 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/extensions/MultimediaViewer@master] [dev] Replace Grunt tasks with NPM scripts

https://gerrit.wikimedia.org/r/574636

Change 574636 abandoned by Aron Manning:
[mediawiki/extensions/MultimediaViewer@master] [dev] Replace Grunt tasks with NPM scripts

Reason:
Misinformed review

https://gerrit.wikimedia.org/r/574636

The parent task has no discussion about this. Task still needed and open.

It's worth noting that usage of Grunt has been on the decline for years. Sooner or later it will become unfeasible to use and a transition will be necessary. Forward thinking has its benefits.

In T266977#6598120, @Aklapper wrote:

Reflecting discussion in Gerrit that this should not be done.

The discussion was concluded as a misunderstanding on the part of Jdforrester. Please read my comments. Closing this task was a unilateral decision, please avoid repeating that mistake.
As the only active contributor to MediaViewer, I can assure you there is good reason to make this transition. If the reasons are not understood then the appropriate action to take is to discuss it.

That's not my understanding; see https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MultimediaViewer/+/574636/41#message-0815c4a6a545a70fa817a792db996118d6f0c0a6

As I've said read my comment detailing the "misunderstanding": https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MultimediaViewer/+/574636/41#message-6bc135e88a5cda27f27045871676ecdbf0216c21
The comment you've referred to is factually wrong. I've explained the facts, if those are not understood then I can't help further.
Please make sure that this discussion continues collaboratively and professionally, without edit-warring on a Decline flag.

As I've written sooner or later this transition will happen. For developer productivity it should happen now. There are no blocking issues, but anybody who thinks there is, is welcome to explain.
In lack of such reasoning, please reopen the ticket as there was no reason to decline in the first place.
I also ask you to make sure such disruption does not happen in the future. Thank you for making this a collaborative environment.

I don't think that removing people from the task subscribers list (after they added themselves to the subscribers list) is constructive behavior.

@Aklapper this discussion is about unilaterally declining a task with a clearly false reason. Can you please discuss that without making accusations and correct it?

Please recall our previous discussion about administrator conduct and neutrality. My hope was that that issue won't repeat itself and we can discuss technical matters with technical arguments in the future.

I think the higher-level issue here is that things like the CI framework should be determined by the extension maintainer, not drive-by contributors as these are long-term choices with significant impact on future work on the code (and sometimes on future work on other code, such as the CI infrastructure). @Demian has done a significant amount of work on MediaViewer, and the extension is unmaintained, so wanting to make maintainer-level decisions is not completely unreasonable, but the maintainer role is not something people should just get on a "who applied first" basis either, especially for a feature that's used very prominently on all Wikipedias.

We do have policies around this; see Maintainers, Requesting +2 (a prerequisite for being a maintainer) and Code Stewards. So, if you would like to make major technical changes around the component without consensus, you should work towards these.

@Tgr thank you for your insight! I'll look into maintainership, though I don't expect that would avoid consensus. Does it?

Certainly I had no intent to make these changes without consensus. I've been asking reviews since Feb 25 and prepared the parent task on Feb 27 to gain feedback. This gained little results though as in 8 months there was hardly any engagement and none with the determination to achieve something. In this time I've been developing with this setup and it saved me many hours. And yet, I did not want to merge this change without consensus, nor plan to in the future - which would be the disallowed +2-ing of my own patch and I don't even have +2 :)

The issue now is an unexpected and unsolicited -2 on the patch and declining the task unilaterally, without any attempt at consensus:

• I've just created the ticket this day and it was closed twice without discussing it. The patch was also rejected.
• It was closed with the false claim this migration was rejected in the parent ticket. In fact the parent ticket is not rejected and MMV was never discussed in it.
• It was closed by a developer not working on the MediaViewer project and not having contributed to it notably. It is clear the context and benefits of this change was not considered.

This is enough to prove the close was inappropriate and unconstructive. Closing the ticket blocks the possibility of community collaboration.
"Unacceptable behavior: [...] Harming the discussion or community with methods such as sustained disruption, interruption, or blocking of community collaboration" (ref) applies.

Currently I'm the only developer actively working on MMV, this makes it hard to find reviewers and engagement. I appreciate any constructive input and collaboration, however, unreasonably fighting to close down my work is neither constructive nor collaborative. It's a great letdown.

As this project practically has no maintainers and other projects are not in scope, the effect and risk of this change is minimal. There should be no reason for a hard veto.
Indeed this ticket requires a discussion and I'm looking forward to it if I can find people interested, that was the reason to create the ticket in the first place.

In T266977#6598346, @Demian wrote:

@Aklapper this discussion is about unilaterally declining a task with a clearly false reason. Can you please discuss that without making accusations and correct it?

@Demian: I did not make an "accusation". Instead I described your actions (see T266977#6598049) which neither seem constructive nor helpful.

"Criticize ideas, not people." The etiquette applies to everyone I believe.
To clarify: the "idea" is to improve developer productivity by replacing an outdated tool with present day solutions. That topic wasn't discussed, only me.
As I'm the only engineer working on MediaViewer and I'm doing so for free, I find this treatment very disrespectful. Such treatment is an obvious contributor to the developer decline (T160508).

@Aklapper My last attempt to reason was T266977#6598937, that proves the actions taken on this ticket were inappropriate. It seems to me this is ignored.
An administrator is expected to do better than to enforce a unilateral and unexplained close, therefore this is a complaint regarding administrative conduct. Repeatedly. I ask you to correct the inappropriate actions.
Per your job description: "Communicate widely and frequently (while being transparent)" (ref), would you give a sound, technical explanation of the reason to close this ticket after it became clear there is a disagreement about it and that the close was unilateral?

Also @Jdforrester-WMF would you like to give a technical explanation - without referring to unclarified sources - for closing the ticket before it was discussed?

The etiquette applies to everyone I also believe and I don't know why it is brought up here as I described previous actions of yours ("previous actions of yours" does not equal "you") as neither constructive nor helpful. Adding FUD like "developer decline" etc unfortunately looks like a continuation of that non-constructive behavior. :(