Change #1199002 had a related patch set uploaded (by Atieno; author: Atieno):

[mediawiki/core@master] Update credits ahead of the 1.45 release

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

Change #1199002 merged by jenkins-bot:

[mediawiki/core@master] Update credits ahead of the 1.45 release

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

(Regarding this comment I left on the previous Gerrit patch)

@Hechtsuppe, how would you prefer to be attributed in the MediaWiki CREDITS file (also visible at Special:Version/Credits)? Currently, you're attributed as My Name, from the specified author-name on this patch. I'm asking as your Wikimedia username is Cmuelle8, but your Phabricator username is Hechtsuppe, so I don't know which of those (if either) you might prefer :)

Change #1199303 had a related patch set uploaded (by A smart kitten; author: A smart kitten):

[mediawiki/core@master] CREDITS: Remove duplicate entries; update contributor names

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

Current status: awaiting confirmation on the Gerrit patch of folks' preferred attributions (see this set of comments).

In T408401#11318421, @A_smart_kitten wrote:

@Hechtsuppe, how would you prefer to be attributed in the MediaWiki CREDITS file (also visible at Special:Version/Credits)?

This is so absolutely unimportant.. I may bring to notice that there are a lot of bugs pending and a lot of spots where mediawiki development lags behind related projects, for example the lesscss parser. If people please could focus and get active on what actually moves the usability of mediawiki forward, rather than handling bureaucratic off-field jobs, that'd be marvelous.

For what I've been concerned with these are open tasks T396802 and T403108. While the reason given to block T396802 at least exhibits some technical insight, it lacks an alternative solution or proposal to implement the feature. Concerning T403108 the only commenter to date completely refuses to acknowledge that phabricator indeed is the right place to tackle the bug and tries to reimagine a solution as a manifold repeated workaround in the countless mediawiki instances.

While I'd like to see those tasks worked on more seriously and at a raised priority from what they have been handled with, this personal preference should not distract from the general point made, that a lot of tasks need more attention.

@A_smart_kitten If you need a consent to close this task, just leave it as is, any string is fine.

In T408401#11342435, @Hechtsuppe wrote:

In T408401#11318421, @A_smart_kitten wrote:

@Hechtsuppe, how would you prefer to be attributed in the MediaWiki CREDITS file (also visible at Special:Version/Credits)?

This is so absolutely unimportant.. I may bring to notice that there are a lot of bugs pending and a lot of spots where mediawiki development lags behind related projects, for example the lesscss parser. If people please could focus and get active on what actually moves the usability of mediawiki forward, rather than handling bureaucratic off-field jobs, that'd be marvelous.

With respect, I feel your comments may be misplaced here. I am not disputing that (e.g.) many other tasks could do with being solved. I'm just a volunteer like you, and - among other things - I take a personal interest in the credits being updated every MediaWiki release cycle. Nobody has asked me to do this - the reason I pinged you was just to try and ensure that you are attributed for your contribution as you wish to be. Again with respect, I would ask you to bear in mind the Phabricator etiquette & Code of Conduct when commenting on tasks in the future.

In T408401#11342510, @Aklapper wrote:

ABreault-WMF closed this task as Resolved.

Closing again.

Huh @Aklapper? I'm confused - I mentioned in T408401#11318376 that the patch needed a follow-up, and the follow-up hasn't been merged yet

@A_smart_kitten Please step back. I did not assault you in any way whatsoever. I have expressed my concerns about the project in general and there is no wrong place to do so. If you feel this has been tailored in any way to you, it was not. I uphold my argument that time spent elsewhere is time better invested.

This is so absolutely unimportant.. I may bring to notice that there are a lot of bugs pending and a lot of spots where mediawiki development lags behind related projects, for example the lesscss parser. If people please could focus and get active on what actually moves the usability of mediawiki forward, rather than handling bureaucratic off-field jobs, that'd be marvelous.

"people" aren't a uniform body that can just work on any ticket. This type of comment is not helpful as it only discourages people to fix things. There will always be something that is considered more important.

@Hechtsuppe Come on man, they are just a volunteer and they asked you what name you prefer. That is a nice thing to do. Please reconsider.

. I uphold my argument that time spent elsewhere is time better invested.

That's fine but this ticket is not the right place for that and it will have no influence whatsoever on what you are trying to achieve.

Ok, no hard feelings. I didn't expect "people" being offended by the comment. I just don't feel this is moving things forward, technically. Some bugs are pending since months with no constructive input which is also a tad frustrating.

Thank you for that response @Hechtsuppe , I hear you. Trying to come up with a constructive way to channel the frustration. I think the best you could do is to let people know over here.. if this is about general priorization of MediaWiki (platform) related tickets.

https://www.mediawiki.org/wiki/Platform_Engineering_Team

https://www.mediawiki.org/wiki/Platform_Engineering_Team/SOPs/Intake_Process

https://office.wikimedia.org/wiki/Request_Funnel_Framework

See, there are a lot of people authoring on instances of this software, and with every day serious or even subtle bugs are not worked on here, 'creative' workarounds in these instances are written and developed that are hard to impossible to revert later on. Because, just as is here, emotions of the workaround authors do play a role if they are to adopt a (then official) feature that renders the workaround irrelevant.

However, implementing core features at mediawiki core, is a good thing to do. For instance, as long as there are concurrent templates (in different language instances) that work around a specific mediawiki technical shortcoming and that try to achieve the same thing, this is source for simmering conflict. Naturally, authors working in one language version with a superior workaround template, will at some point try to replace the inferior instances (read synchronize) with the latest-and-greatest version in the other instances. This is invention travelling around mediawiki core, and an indication that the copy+pasted bits should probably be a part of the mediawiki roll-out itself.

You are probably right that this is the wrong place to raise the issue, though, let alone that others are aware of this problem.

Sorry, I should have elaborated - the reamining open patch does not block "Release MediaWiki 1.45.0" (the parent task).

In T408401#11345791, @Aklapper wrote:

Sorry, I should have elaborated - the reamining open patch does not block "Release MediaWiki 1.45.0" (the parent task).

It does though (at least, IMO) -- the current CREDITS in REL1_45 contain some duplicates & non-preferred names that were added in the original patch for this task; which is what's being resolved with the follow-up patch (which IIUC will be backported once merged). Anyways, hopefully it should be ready & merged/backported within the next week so I guess (hopefully) it's somewhat moot.

In T408401#11345817, @A_smart_kitten wrote:

It does though (at least, IMO) -- the current CREDITS in REL1_45 contain some duplicates & non-preferred names

It doesn't... It is very much possible to release MW 1.45.0 with duplicates and non-preferred names. :)

Yeah, but - if I'm being slightly tounge-in-cheek - it's technically possible to have MW1.45 released without updating the CREDITS at all. But IMO these fixups should be done before the release - IMO we owe it to newly-listed contributors to get their names right in the CREDITS of the first release they'll be listed in.

To be honest, more than anything, I guess I'm just confused as to why this needed to be closed at all, given that everything seemed to be progressing okay, with the second patch on-track to be merged & backported in time for the release (AFAICS); meaning that fixing-up the previous CREDITS patch wouldn't push the actual release-date back. TBH, it strikes me that it just makes it harder to keep track of things. But like I say, it's probably moot.

Change #1199303 merged by jenkins-bot:

[mediawiki/core@master] CREDITS: Remove some duplicate entries; update some contributors' names

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

Change #1203125 had a related patch set uploaded (by Arlolra; author: A smart kitten):

[mediawiki/core@REL1_45] CREDITS: Remove some duplicate entries; update some contributors' names

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

Change #1203125 merged by jenkins-bot:

[mediawiki/core@REL1_45] CREDITS: Remove some duplicate entries; update some contributors' names

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