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)