User talk:Krinkle

Kois}}

"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)