I like to tinker, I like to implement and improve things for myself, I like the idea of collaborative and public good efforts being to the advantage of everyone, I'm a very good systematic and structured thinker, I like learning, I'm good at it, I like efficiency, I like creativity, I like some stuff that you can get out of it. And for better or worse; honestly worse; I have nothing "better" to do, so I end up with projects even after work.
It was not a conscious decision to get into it. I slid into it. Using software and web, contributing content, changing websites, themes, game scripting, hosting, and then more and more development.
I can certainly understand and relate to loneliness within the job. I've been fully remote for a long time now, with social anxiety, which at the same time makes it more sustainable but also not a good or healthy situation.
I'm lucky to have a very small and good team, work environment, and customer. Such a good situation makes it hard to leave as well.
I am interpreting "don't particularly favor" as not particularly significant nor important for me personally nor in general.
Add a comment
explaining, in subjective wording, why I prefer it differently
adding a change suggestion that may or may not be applied to demonstrate it
a personal conclusion and assessment, how important or significant it is to me, and what's fine by me even if not my preference; e.g. "pick what you prefer or want" or "consider change effort"/"fine for now" or whatever
I feel like "sending back to the owner" sounds too strong; although it practically is that, it is not about sending it back; I share my opinion and view, and let the owner decide at their discretion
Whether I suggest a guideline depends on what it is; whether consistency and conformance would be useful in such a case, not for personal, subjective preference, but for code consistency or because they end up preferring my suggestion too.
Null coalesce operator vs comparison operator precedence? Both questions are about that. I don't see one having a different answer to the other. In that case, duplication would only lead to spread out partially outdated information, instead of one place being updated.
I asked 1 high-quality question in 2024, and it was closed almost immediately, and I haven't engaged with the site since.
If someone with 20,000+ karma has their nicely-formatted questions closed so quickly, what must the newbies and rank-in-file encounter? This is probably a big reason why it's declining.
It's a high quality question, yes.
The close as already answered elsewhere is valid though. It's not saying that the question is wrong; at least a decade ago StackOverflow explicitly allowed and encouraged asking the same question in different ways so they and their answers can be found.
It's about operator precedence. And the referenced question asks the same thing, about ?? and a comparison operator.
The head note says:
This question already has an answer here:
Notably, it refers to answers, not the invalidity or duplication of a question.
The header also mentions [previously] opinion based, so I looked into the question edit history. It most certainly was not a "high quality" question at the beginning - at the very least to the degree it looks like now.
Ahead of Legion Go S shipping, we will be shipping a beta of SteamOS which should improve the experience on other handhelds, and users can download and test this themselves.
So, neither that product is rolling out yet, nor the SteamOS beta is rolling out yet?
(This quote is from Valves announcement, but meaning-equivalent to the linked article sentence regarding it.)
Exactly. It's a matter of barrier and interest. Signup requirements are a barrier to drive-by improvements and reports, and them as entry points to further contributions.
... Stirling PDF focuses on performing various operations like splitting, cropping and rotating on your PDFs. PdfDing however has a different focus, it is all about reading and organizing your PDFs. ...
You picked one concern of multiple: Code discoverability of an already known project.
Multiple times I have found project sources on their own platforms, and when I would have contributed tickets or code, I did not because of requiring yet another account on yet another platform, with whatever yet unknown signup workflow.
And there is man other concerns, some of which the comment you are replied to mentioned.
we will officially begin rolling out our initiative to require all developers who contribute code on GitHub.com to enable one or more forms of two-factor authentication (2FA) by the end of 2023
If your account is selected for enrollment, you will be notified via email and see a banner on GitHub.com, asking you to enroll. You’ll have 45 days to configure 2FA on your account—before that date nothing will change about using GitHub except for the reminders. We’ll let you know when your enablement deadline is getting close, and once it has passed you will be required to enable 2FA the first time you access GitHub.com. You’ll have the ability to snooze this notification for up to a week, but after that your ability to access your account will be limited. Don’t worry: this snooze period only starts once you’ve signed in after the deadline, so if you’re on vacation or out of office, you’ll still get that one week period to set up 2FA when you’re back at your desk.
They also describe why the requirement makes sense/is necessary.
No mention of commenting issues etc. I suspect missing 2FA is just one factor that got you flagged.
they’re actively alienating users who want to use open-source, because those users cannot get support, report bugs or contribute to the project without using proprietary software
You can still use their source and software though.
Surely, they have their reasons for choosing GitHub over other alternatives.
I know I do, when I choose GitHub over others. (I'm not choosing Discord though.)
Reviewing every change and discovering every issue is unfeasible on multiple levels. Even skipping that fundamental, base level requirement; you need to trust in trustworthiness from submitters and reviewers, and that people review. You need to trust those maintainers that can push and pull and merge. You need to trust the builders and publishers and distributors.
I doubt you're reviewing every code change and compiling or verifying reproducible builds on every software and patch version you run. You put trust in the chain. And the chain decided to cut at some point because of risk.
Besides, the idea that employed developers with a Russian day job are a risk… but one fails to consider these were the honest ones who declared their day job.
So you think people do only one job and have only one concern? Do you think people of sanctioned countries, contributing to an unjust war, more or less directly, are a bad place to start reducing risks?
I feel like properly vetting commits to the kernel that does not involve the core contributors and maintainers too much is the way to go.
I'm baffled you can make this point while at the same time not accepting their decision after review, assessment, and consequence. You're asking them to review while not accepting their decision. From the same people.
I've read interesting argumentation against nesting. I'm not confident in whether it's more useful or not, in some situations or in general.