User talk:Krinkle

"Avoid namespace numbers above 10,000. These are reserved for future use."
Can you give any detail what you meant by "future use"? Is there some WMF project in the works that will use numbers in this range, or was it maybe meant as a more nebulous "we don't really need these yet, but we might some day" thing, or something else? 「 ディノ 奴 千？！ 」☎ Dinoguy1000 13:38, 30 July 2019 (UTC)
 * We might need them someday. It's there so that developers won't interpret the advice as "pick a random number between 5000 and 9007199254740991". But rather put a more reasonable limit on it, which might get extended one day after a discussion to another reasonable limit. --Krinkle (talk) 14:43, 30 July 2019 (UTC)
 * Aah! Fair enough; that's about what I figured. Though personally I'd be somewhat surprised if we ever actually get to that point; it seems like much fewer extensions are being written these days which add namespaces than were written in the past... 「 ディノ 奴 千？！ 」☎ Dinoguy1000 16:06, 30 July 2019 (UTC)

My message on T20493
I was wondering what you thought of my suggestion on the Unify the various deletion systems thread.

My suggestion was made in response to specific sites that I know of where RevisionDelete is not generally available to local Administrators, as it is generally reserved only for TOU violating issues.

And in response to my belief that there ought to be an extension to the traditional deletion system allowing for individual or multiple revisions to be deleted and moved to the archive table, as opposed to being limited to deleting all revisions and then restoring the wanted revisions. If such an ability were to exist, I would imagine it sharing the same pages as the traditional deletion ability, via ?action=delete.

But if the page deletion system and the revision deletion system were to be merged together, how will we be able to find a way to please those sites that prefer not to give Administrators the ability to selectively delete revisions by default? ― C.Syde  ( talk  |  contribs ) 05:13, 1 August 2019 (UTC)
 * Thanks, I've replied at https://phabricator.wikimedia.org/T20493. --Krinkle (talk) 13:23, 1 August 2019 (UTC)

new wiki ideas
i have many. any idea where i can start a new wiki project? thnx. Baozon90 (talk) 22:46, 3 October 2019 (UTC)

About Compatibility
Hi. Since you removed the page Compatibility from translation, all of the existing translation pages were deleted. e.g. Special:Undelete/Translations:Compatibility/1/es --Shirayuki (talk) 01:43, 19 October 2019 (UTC)
 * @Shirayuki:
 * They were not deleted, they were converted to regularly editable pages, with the shared tables as templates. I made sure every translation was preserved, such as for Spanish at Compatibility/es. I did this on 3 October 2019. Please undo your changes as they have caused the translations to actually be hidden, as you can see in this diff which shows the Spanish page has now become English. --Krinkle (talk) 19:51, 19 October 2019 (UTC)

Username change on phab
Hello, Krinkle!

You're the only phabricator admin I know... how do I request a username-change on phabricator and also for git? Thank you. — Aron Man. 🍂 edits 🌾 11:25, 24 January 2020 (UTC)

Pinging. — Aron Man. 🍂 edits 🌾 13:20, 6 February 2020 (UTC)
 * @Aron Hi, I can't help you directly. Please file a task on Phabricator and wait for an admin to help you. --Krinkle (talk) 18:39, 6 February 2020 (UTC)
 * Thanks! That's what I was looking for. — Aron Man. 🍂 edits 🌾 21:13, 6 February 2020 (UTC)

Help wanted
Hoi Krinkle,

Zou jij me kunnen helpen met een simpele extensie? Zie mijn overlegpagina voor de details.

Bedankt. --RenéV (talk) 20:23, 1 February 2020 (UTC)
 * Hoi! Ik heb op je overlegpagina een antwoord achter gelaten. --Krinkle (talk) 18:43, 6 February 2020 (UTC)

Discussion continued
Hello, Krinkle!

I think it's better to discuss this on-wiki, not on the Gerrit patch, as it is not a technical discussion. Continued from: Patch 579245.


 * > You mentioned that cleaning this up is "low priority" and can be done later. That is in my opinion the definition of technical debt.

I understand your point. In my experience in the Wiki sphere "later" more often than not means never. I'm trying to get some years old tasks solved that fell victim of "later". However, that's not how I work. Priority means there is sequence, but very little gaps between the steps. I don't have the comfort of a "no consensus now" solution, that's a failure in a for-profit setting.


 * > When managing a project of this size, one cannot just hope someone will clean it up later.

"Follow-up." I haven't heard many people use this word around. I see this as cultural issue originating from the wiki model. There's something to be learned about finishing what we started.


 * > However, it is part of the responsibility for a patch contributor to apply that feedback and not leave the code in a worse state than before.

We have different practices and focus. I never remove a hashbang, as it is the equivalent of the magic number / type specifiers at the start of files. For this reason as I've said I don't endorse removing it, it's your decision and responsibility.

Anyway, thank you for finishing and merging this patch. I appreciate the quick response this time, this is how I imagined you would do your cleanup if you find it important.


 * > As written, this patch leaves an unused hashbang behind. It is not hard to imagine that a future contributor will follow the path in package.json, and open the script, and once there, (wrongly) assume that the hashbang is used, and that they can change it. For example, they could write the script in php, update the hash bang, test it, and later find that it breaks from package.json.

Thank you for the explanation of the "technical debt" issue you see with leaving the hashbang as it was.

I'm sure the CI build - right after said contributor submitted the patch - would fail to run the php script with sh and the contributor would need to fix package.json in the second patch set already. I think such fixes are normal and usual as many tests only run in CI, therefore I don't find that a problem in any sense, nor a debt. This is the reason why I don't share your concern. I hope this makes my point of view understandable.


 * > It's great that you want to contribute, and there is a lot to do.

Unfortunately, I don't experience the "great" part. In my experience volunteer effort is handled in a counter-productive way, often times unappreciated and sometimes even disrespectfully. The opposite that I usually experience while contributing to open-source.


 * > However if you are not prepared to also do the clean up required, then we cannot accept your contributions unless you collaborate with another volunteer that will, or that the work aligns with something I can spend more time on to finish your patch.

I think this fundamentally misinterprets my modus operandi. I do significantly more cleanup than many of the developers I have met and observed their work. In this case there was a disagreement of what should be cleaned up and the importance of it.

If you observe my contributions you might notice that I prompty apply all feedback and also do extensive research of discussions going back years to find out what the purposes and plans were. Please recall when I've cited you from years ago in another task. You won't meet many contributors, who does such extensive research to find all the requirements for a solution. I hope you appreciate that. I don't have bad feelings about your comment, I reckon I wasn't either as nice to you as you are usually.


 * > But please consider this when you interact with open-source maintainers in the future.

I will and I hope my perspective will be considered too.

— Aron Man. 🍂 edits 🌾 23:00, 15 March 2020 (UTC)

Rebasing
Continued discussion from gerrit about commit messages not copied to master branch when jenkins-bot merges patches not based on HEAD.

Myself, previously:

> My concern with jenkins-bot merging instead of rebasing the patch is that the commit message is lost from the master branch. Every time I have to look for the merged patch in git and that takes time, unnecessarily. It makes much harder to browse the history effectively. I think jenkins-bot could be persuaded to rebase instead and keep the commit message.



Krinkle:
 * > I suspect that might be an issue with the tools or configuratin of the git viewer you use. }}



I'm sorry if my comment could be misunderstood, I'll try to explain better. This is not an issue with the tools. If you visit a merged patch that wasn't rebased on HEAD, you'll see something similar to: https://github.com/wikimedia/mediawiki/commit/7ef1f1d865431a6f8f041f5e2ea83ce5aa0cd1ff

Can you tell in a blink: - who made the patch? - with what reason? - where is the commit comment?

If you have a good git gui - I use Fork (available on Mac, highly suggested ;-) and GitExt - you can step through the commits with one keypress and read the commit message, thus gain an understanding about what's going on in a few seconds. Very efficient.

But not with patches that read only: 'Merged "some patch title"' by a bot. I do more and deeper research in the git history than people usually do, therefore I understand this did not come up as a pressing issue. However, I ask you to understand this issue and think about it on a relaxed day.


 * > As an example, you'll see here https://github.com/wikimedia/mediawiki/commits/master virtually all of those are done with merge commits. That is our chosen practice which has some benefits and some downsides. Please follow those practices for now.

I'd be interested in the benefits and downsides you're aware of, to understand the constraints here, but I think we were talking about different things: There is no "practice" in this, patches randomly - depending on activity - get either merged or fast-forwarded.

— Aron Man. 🍂 edits 🌾 21:45, 29 June 2020 (UTC)


 * Hey, Krinkle!
 * Did you receive this message? Did I manage to clearly explain the problem?
 * If this needs more discussion on phab, please inform me of the tags to add and I'll make a ticket.
 * I hope this could be improved as simply as adding the equivalent of `--rebase` to jenkinsbot merging. Please point to the source code and repository where this should be found.
 * Thank you! — Aron Man. 🍂 edits 🌾 11:24, 2 July 2020 (UTC)
 * Thank you! — Aron Man. 🍂 edits 🌾 11:24, 2 July 2020 (UTC)


 * @Aron: I understand you may be used to using Git differently. The concept of a merge commit is native to Git. This means it offers various benefits whilst also therefore being a recognised concept that most if not all Git interfaces can hide or skip when appropriate. For example,  and   operations generally ignore merge commits by default, automatically. The same applies to GitHub's versions of these as well (file history and file blame).
 * The repository-wide histories do show them by default, which I find useful. However every Git CLI and UI I've used also have options to hide them. If that is your preferred way of showing the logs, I recommend you use those options. See also git-config and Git/aliases. --Krinkle (talk) 19:00, 24 July 2020 (UTC)


 * Hi again!
 * As the GitLab transition has been torpedoed and seemingly abandoned or delayed for an unknown time, this issue became relevant again. I'm concerned that the advice you gave about git aliases has nothing to do with this issue as the list of commits to show in git cli is independent of the length of git commands and GUI clients don't use git aliases. `abbrevCommit` is also irrelevant, the issue is not whether the commit id is 10 or 40 char long. I wonder how that relates to this issue for you. I also wonder how you use Git if you believe I use it "differently". Different from what and in what way?
 * Generally I'd like to ask you to understand the problem I've detailed above and instead of giving advice that's hardly useful or necessary, you could introduce your workflow and tools that you use to mitigate this issue when browsing or searching the git history for information that can be anywhere within a few hundred commits (that's maybe a few weeks' worth of changes), without any exact clues to heuristically speed up the search - by which I mean a linear search is necessary.
 * I assume what you meant by using git differently is that I do research that goes this far and deep and probably nobody else at WMF does. Going this deep is the reason why I find the cause and origin of certain decisions and issues. I'm happy to teach this technique if I'm asked, on the other hand I'd like to ask you to make applying this procedure easier. As I've detailed before it does not take much to increase developer productivity significantly.
 * I also wonder why it is so hard to communicate this issue. If you could give any advice how I could present this issue more clearly, I'd appreciate.
 * Regarding the support of merge commits: as far as I'm concerned that's baseline in tools nowadays. The problem in this case is not git blame and history continuity, but the overwhelming noise that merge commits generate by 1) missing the relevant information from the original commit 2) creating 10-20 parallel branches (in the very active core repo) just for individual commits that's redundant (the exact duplicate except for the commit message) with the merge commit. This is what I described as rainbow-colored spaghetti that you can see in the screenshot. Without merge commits (with commits rebased on HEAD before merge) that would be a single line of consecutive commits without duplication. I think there's no need to further explain how simpler that would be to comprehend and handle for all developers.
 * Thank you for reading this. — Aron Man. 🍂 edits 🌾 17:51, 19 August 2020 (UTC)

RTRC translations
Hello Krinkle,

I would like to report a bug in RTRC. At the moment, atleast for me, translations are not visible in RTRC. From what I gather from the DevConsole it seems to fail because a header is missing (see below). I think that might be because the domain changed from tools.wmflabs.org/intuition to intuition.toolforge.org

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://tools.wmflabs.org/intuition/api.php?domains=rtrc&userlang=nl. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://tools.wmflabs.org/intuition/api.php?domains=rtrc&userlang=nl. (Reason: CORS request did not succeed).

Could you please take a look at this when you have the time? Thanks in advance. Kind regards, Wiki13 talk 07:21, 8 July 2020 (UTC)
 * As of 2 days ago the translations started to work again, so you can ignore this message. --Wiki13 talk 12:53, 11 July 2020 (UTC)

GUC Tool error, or?
Hey there. I'm looking at the Mass Message tool contribs.
 * (diff | hist) 16:51, 10 Jul 2020 . . ua.wikimedia.org . . MediaWiki message delivery (talk | contribs) . . Обговорення:Вікімедіа Україна (→‎Announcing a new wiki project! Welcome, Abstract Wikipedia: нова тема) (current)
 * (diff | hist) 16:51, 10 Jul 2020 . . pl.wikimedia.org . . MediaWiki message delivery (talk | contribs) . . Dyskusja:Strona główna (→‎Announcing a new wiki project! Welcome, Abstract Wikipedia: nowa sekcja) (current)
 * (diff | hist) 16:51, 10 Jul 2020 . . no.wikimedia.org . . MediaWiki message delivery (talk | contribs) . . Wikimedia:Samfunnet (→‎Announcing a new wiki project! Welcome, Abstract Wikipedia: ny seksjon) (current)
 * (diff | hist) 16:51, 10 Jul 2020 . . nl.wikimedia.org . . MediaWiki message delivery (talk | contribs) . . Wikimedia:De kroeg (→‎Announcing a new wiki project! Welcome, Abstract Wikipedia: nieuwe subkop) (current)

These entries are about a message I sent. However, for some reason, the rest of the messages I sent in that batch is missing from the log, and you can verify following any link in here that the message was indeed sent out correctly. What gives? Should I report this issue elsewere or to someone else? TYVM! Elitre (WMF) (talk) 13:30, 13 July 2020 (UTC)
 * @Elitre: GUC shows at most 20 results per wiki. Perhaps that explains the missing entries? If not, please file a task on Phabricator under GUC. --Krinkle (talk) 19:12, 24 July 2020 (UTC)
 * I will. GUC shows (or at least should) all the results when ordered by date. TY, Elitre (WMF) (talk) 08:55, 28 July 2020 (UTC) PS: https://phabricator.wikimedia.org/T259454. Elitre (WMF) (talk) 08:23, 3 August 2020 (UTC)

A problem
Hello Krinkle. Since you are an active MediaWiki admin who you speak Dutch, I am writing to you. Also, since I know you from Meta, it isn't difficult to find an user who speaks Dutch. , this user translates the messages for different languages here, on Meta, Wikidata, Translatewiki etc. According to the different accounts of this user, I will say that his native language may be Turkish, but even the Turkish messages he wrote on Translatewiki and Turkish Wikipedia were corrupted. At the beginning of 2020, we (users of Turkish Wikipedia) had determined that these were machine translations. And because the translations were unfortunately wrong, different users on Turkish Wikipedia tried to reverted translations from different projects. I think these are still machine translations, as he is making translations for many languages ​​in the world. I haven't checked the translations as often as before, but the user says he speaks Dutch. Translations:ORES/91/nl Translations:ORES/91/en Is this translation correct for Dutch? If many of these translations are wrong, something needs to actions for this user. Because there are hundreds of thousands of translations here. Uncitoyen (talk) 08:48, 14 February 2021 (UTC)
 * @Uncitoyen: The translation at Translations:ORES/91/nl looks good to me. I would argue it is even superior to the original English source, and do not believe it to be a machine translation. Thanks for asking! --Krinkle (talk) 19:19, 5 March 2021 (UTC)

Krinkle
Krinkle Krinkle Krinkle Krinkle Krinkle Krinkle Krinkle Krinkle 37.48.58.45 09:10, 8 March 2021 (UTC)