301–310 of 364 posts
Earlier quoted context omitted.
> Vetting a possible maintener or fork is >0 work Who said anything about vetting?
Because people also complain when new maintainers are added and those maintainers cause problems or even abuse the project to insert malware. You can't win.
Earlier quoted context omitted.
> Vetting a possible maintener or fork is >0 work Who said anything about vetting?
Because people also complain when new maintainers are added and those maintainers cause problems or even abuse the project to insert malware. You can't win.
If the new maintainers cause problems, it's their problem, so the "you" in "you can't win" would of switched between maintainers.
Earlier quoted context omitted.
> people with kids win at life That's a pretty insulting statement for those of us who can't have / don't want children. It's not a competition. We've chosen different paths than you. Not worse, just different.
Kids make you happy, but only when they move out as as long as they don’t break the bank. Truth is having kids is a kiss of death for your creative and professional career. E: Of course downvotes. Truth hurts. Let’s see how grey my comment gets.
Kiss of death seemed melodramatic at best though. Every CEO, CTO, and CFO I've worked with had kids. Guess they were the lucky few who didn't have their professional career ruined by those goblin children?
I agree: it is OK for your open source library to be a bit shitty. However, it also can simultaneously be not OK for you to publish it in a package directory with a generic name and a description talking about how awesome it is as a trap for other people to run into, and that is really the core problem: it isn't that you didn't spend an unreasonable amount of time and money to make a good product that no one paid for…
I'm observing this regularly. Currently a bit more in the Rust community since I'm more active there, but I think it's a thing that happens everywhere.
I think in most situations it happens is is incidentally: The people who wrote those packages do not actually have the experience to observe design and quality issues in their package. They might still be in university, or have a minimal amount of industry experience, and found working on an open source project to be a nice way to be creative.
And in one metric that they found for themselves, the might even beat very established projects - let it be performance or finding the new "ultimate abstraction". Therefore they are going forward to market the project as the awesome new thing - without knowing about other important metrics that their project does not meet.
I'm not sure how this can be improved. I think it would require experienced reviewers and curators that are willing to look into other peoples open source projects and help them. As well as authors of those projects to be willing to be mentored. Both is not easy. As an experienced engineer you have enough to to that you don't want to look into YetAnotherProject. As someone who wants to hack on a side project as much as possible you probably don't want to waste your time with talking to someone else.
Earlier quoted context omitted.
That's terrible. I am a manager and actively discourage people from working late / weekends. I find it's not sustainable. People who do that, regardless of children status are much less predictable in their output. They go through peaks of productivity and then they crash. It also ends up happening that they work on the wrong thing because no one is around at night or weekends to answer basic questions that may unfor…
> It also ends up happening that they work on the wrong thing because no one is around at night or weekends to answer basic questions that may unfortunately not be in the ticket. I know the comment came from a good place and you meant well. The situation you describe of “developers working on the wrong thing” can and sometimes does happen, however, as a manager the effective way to handle those situations is to addre…
I agree that a manager shouldn't micromanage to the point that they believe developers cannot be productive without their manager physically present, but that is not what they were talking about. The comment isn't about the developer needing their manager's insight or guidance, but about the developer needing the expertise of the rest of the team, which they will not have access to at nights or on the weekend.
Earlier quoted context omitted.
If anyone is in any doubt about this, I would like to point them towards this github issue: https://github.com/mrc-ide/covid-sim/issues/165
I don't even know where to begin with this, it's so insane. It's extra funny because John Carmack was the one who did a lot of the refactoring of this code. It's also not remotely true that billions of lives have been disrupted on the basis of this code being correct. This is exactly why scientists don't release their code.
In fact, more applications-focused researchers (those who combine real data with established models, for instance) tend to write higher-level scripts stringing more-engineered tools. In this case, open sourcing the scripts would be both easier and more pointless, since they will be almost the same as what is stated in English, tables, and plots in the paper. Epidemiology is usually this way, in my experience, though the linked repository seems to have some of both flavors.
The underlying misunderstand in that issue thread seems to me to be a disagreement on what the main valuable byproducts of scientific programming are. Professionally programmers will naturally think it's the code, but, traditionally, the code has been seen in academia as only a temporary vehicle for the model and it's parameters, which is the real product. (Also, the "program" might really need to include the lab, its papers, and its institutional knowledge, which is harder to package and open-source.)
Right or wrong, the assumption is that any competent grad student could reproduce the result in a week or so of (admittedly unnecessary) greenfield coding. But this is clearly not ideal, and newer work does strive for more professionalism in coding, open-source-by-default, and therefore faster replication. The project in question clearly predates this trend.
(Of course, a third reason academics don't open source is that some secrecy is required before publication in competitive fields. On a months-long project, you might not want to be committing publicly before publication. But this isn't much of an excuse.)
Earlier quoted context omitted.
I need to publish it publicly to install it via pip, npm, cargo, etc. for public use.
This is why I really liked the approach of using a github username as a namespace for rubygems, it lets you publish things but with some indication that it may just be for personal use.
Installing from a generic git URL tends to work just fine, even if it's a bit more typing.
Earlier quoted context omitted.
I don’t doubt it, but covid-sim is not the best example of this effect. In this case, people are worried that poorly written simulation code is informing policy decisions that affect billions of people. They are not demanding that it should be fixed, they are demanding that it should not be relied on in its current state.
They're worried that there isn't testing code to prove that it's correct. If it's proven correct in other ways, it doesn't need unit tests. Yeah, the code's bad – so what? It wasn't written by programmers. Most simulation code is bad, but if it's been proven correct it doesn't need to be good. From what I can tell, this is a matter of conflicting conventions in different fields meeting head-on.