If you lease you car you have to give it back.
If you license your games for the duration of them being active, then it makes sense.
The biggest issue, miscommunication, and often illegal practice is calling it buying when it is only a limited subscription. IIRC Steam recently (finally had to) change the wording away from "buying". Because it's not buying if you don't own the product afterwards.
The collaborative sharing nature of these platforms is a big advantage. (Not just VS Code Marketplace. We have this with all extension and lib and program package managers.)
Current approaches revolve around
The problem with the latter is that it is often not necessarily proof of trustworthyness, only that the namespace is owned by the same entity in its entirety.
In my opinion, improvements could be made through
Maybe there could be some more coordinated efforts of review and approval. Like, if the publisher has a trustworthiness indication, and the package has labeled advocators with their own trustworthiness indicated, you could make a better immediate assessment.
On the more technical side, before the platform, a more restrictive and specific permission system. Like browser extensions ask for permissions on install and/or for specific functionality could be implemented for app extensions and lib packages too. Platform requirements could require minimal defaults and optional things being implemented as optional rather than "ask for everything by default".
What makes you think only GitHub is celebrating?
I would dislike the first/referenced commit description as verbose as well. It describes a user or change drafting journey without ever saying concisely or separately what the commit actually does and why. If it at least had that summary up top in a first block or separated with --- separator it'd be much better.
I like the first part of the suggested alternative but I would never put a discovery journey into the commit message, or a "an hour of my life wasted". I would put them in a MR comment - or separated block in the MR description with the intention of it not becoming part of the merge commit description.
The journey is not relevant to the code and changes. When you think of looking at it one year later, you can see the value of a description of the change, but I don't see value in the discovery journey. The journey is more relevant in team-knowledge and workflow of how to work with the code base, and inter-personal team building.
Too much bloat of irrelevant information diminishes discoverability and conciseness of descriptive and useful information. It's noise.
This is a community for discussing things about programming.dev itself. Things like announcements, site help posts, site questions, etc. are all welcome here.
The strength of open-source
"Killing" seems like an inappropriate term for end-of-support though. That's clickbait to me.
they want to push a lot of buttons on those controls
LOL
Even with a lot of buttons available, good videogame controls are simple and narrow. Natural combinations add depth without overcomplicating things.
In my Firefox I get a NS_BINDING_ABORTED error on the Google Fonts font request.
And they didn't specify a font fallback, only their external web font. It would have worked if they had added monospace as a fallback.
The "rectangle" probably isn't supposed to be this messy?
You're asking about the backend only, separated from the fronted? The fronted will be HTML only, but independent of the backend anyway?
Doesn't that mean you're introducing another interface and a need for another backend for the HTML frontend generating?
If it's independent, why does the frontend intention matter?
My first choice/exploration would be C#/.NET.
Sharing, because I had to look up Abstract Wikipedia