If I told my manager it was his problem to get my code reviewed, he would tell me to do my job.
Offloading responsibility for getting code through review to a manager or scrum master sounds at least as dysfunctional as people avoiding doing the reviews.
> If I told my manager it was his problem to get my code reviewed, he would tell me to do my job.
If that's how you interact with your team members, no wonder they refuse working with you.
What any competent developer does is a) update ticket to move it to review, b) call out the PR in whatever system you guys use, c) after a reasonable amount or time inform your scrum master/manager that your task is code-complete and is blocked by the review, d) update ticket with a notice that PR is still pending review. Go back to step b) and repeat until the PR is merged.
Done.
Updating the ticket and making a best effort to get the ticket moving is all that's expected from you. By design. That's how things are supposed to work. If your manager doesn't care, it's nothing they want to push anyway, as proven by the ticket history.
> Updating the ticket and making a best effort to get the ticket moving is all that's expected from you.
I have never worked somewhere that ran things as you describe. But then everywhere I’ve ever worked has expected a high level of personal responsibility, not “best effort” that consists of a one time Slack
message and tagging work as blocked.
This may be small nuclear team vs sprawling org difference.
This process works so well in a team that are all pushing together.
Moving the ticket along and a slack to the effect of "this one is quick and easy" Vs "this one's a bit gnarly, happy to jump on it with someone" generally sees PRs reviewed very quickly.
A pleading cat gif is usually enough as a reminder.
A well oiled team is working to deliver customer value (internal or external). I've been lucky enough to have had a few teams of incredibly good engineers over the years. So much gets done.
I can see it not working so well in a team of "individuals" focused on their own performance and "personal responsibility" solely for their bit.
The kind of teams that throw everything over the wall to an individual making a build gate go/no-go decision perhaps.
> This may be small nuclear team vs sprawling org difference.
This is very likely a big part of the difference. Most of my career has been spent at very large companies. Smaller teams that can manage to be more inwardly focused with fewer cross, team dependencies, can doubtless operate differently.
> The kind of teams that throw everything over the wall to an individual making a build gate go/no-go decision perhaps.
That’s not really what I described. I ran the process, not the fundamental go/no go decision, which was a distributed responsibility. That was the exact friction, and it’s very similar to the code review friction in large organizations. A PR author has a responsibility for their PR but it may require sign off from numerous other teams.
Some of this is necessary complexity that arises from large teams building large products. Some of it is certainly dysfunction.
When a small team sits close to each other, you can simply say: "hey guys, anyone got time to check my PR?".
In a gigantic org, you can message them on Teams, but everyone keeps getting messages on Teams constantly so they are probably going to ignore you for an hour.
Dude, you're the one talking about talking down to people telling them they are not doing their job. Relax.
> I have never worked somewhere that ran things as you describe.
What do you think a PR reviews process is? It is literally "I will be prevented from merging my work so that all of you may have a say on what I'm doing".
This is precisely how and why it is designed to work.
In basic scrum, you know that part where the scrum master asks in daily meeting whether people are blocked? What do you think it is used for?
Pray tell, what do you think a PR is used for, and how does the process work?
> The place I currently work at operates quite differently.
If your place of work had no one responsible for setting work priorities of managing task delivery and then find yourself blocked by mundane things like a PR then it seems you are developing novel ways of being dysfunctional. Perhaps you PR process is indeed not the problem but a symptom.
It's pretty rare that I get blocked on something mundane like a PR, but if I do I just tend to message a colleague something along the lines of, "hey, can you please take a look at X when you next have a moment? blocking me for Y" and that resolves the issue promptly.
TBH I think micromanaging inter-team communication by turning it into a process that requires a responsible individual to run is far more dysfunctional.
It is managers responsibility to set priorities including those of other team members. Including priorities of code review. That is not offloading. It is also considerably less toxic then "I demand people to be fired because my code review was not done in 12 hours".
Your PR is not the importantest thing being worked on.
What I said is it’s not my manager’s job to wrangle people to do code reviews for me. It’s absurd that the immediate response to friction is to offload it to someone else. Certainly if there is a cultural problem, or misaligned priorities, discuss the general issue with your manager. But “I set the ticket to blocked so I’m done” is not an acceptable process anywhere I’ve ever worked.
Much of the time the person I’m waiting on doesn’t report to my manager anyway. My manager can’t change their priorities any more than I can.
This doesn’t change much though. If there is a general problem, it’s likely appropriate to pull in management to figure out the issue. But it’s probably not a management problem that my specific PR needs a review.
It's literally the most management problem imaginable.
Management decides the process, management decides who to hire, management assigns the roles and management decides how urgent the work is.
If the constellation is so that reviews are required, but the reviewer is not under the control by the manager and reviews do not happen, then some manager somewhere made a mistake.
Why? Because PRs are expected to be reviewed. Any process in which that does not work automatically is dysfunctional and needs to be fixed until PRs are being reviewed properly again.
If everything is working as intended, but it's the manager who created a false sense of urgency and pushed all of the responsibility onto the person who cannot do anything about that, then the only person who can fix the problem is the manager and the thing he has to do is something very easy: be more patient.
Edit: It might not be obvious, but all the things you claim that strengthen your position are already table stakes and assumed to happen regardless. The question is, who is responsible for making the invisible and automatic happen? And you're saying the manager can shirk his responsibility onto the blocked employee, which is hilarious because it means your entire operational strategy for fixing a broken process relies purely on being lucky.
Another thing that might not be obvious but if you write a bad pull request and the reviewer tells you it is bad and can't be merged that's on you as well, no shit Sherlock.
> What I said is it’s not my manager’s job to wrangle people to do code reviews for me.
I'm sorry to say, but it is. Is your manager responsible for managing workloads, task assignments, and priorities?
> It’s absurd that the immediate response to friction is to offload it to someone else.
That doesn't sound right. A PR review literally requires you to dump your workload onto someone else. Often times a PR requires significant amounts of time to review. Your team members need to set aside significant amounts of time out of their schedule to look at your work.
You cannot frame a problem that fundamentally revolves around dumping work onto someone else as being absurd to dump your work onto someone else. I mean, what do you think happens when you ask someone to review your work? Do you expect your team members to blindly sign off?
It's obviously about offloading work. And it's the Manager's job ro set those priorities.
It sounds way more dysfunctional to start doing the managers job to me.
If you think it is your responsibility to get a reviewer on the other side to prioritise reviewing your work then you basically made yourself responsible for hiring and firing people or reassigning their project responsibilities.
By the time you managed to have your review get through you might not even be a developer anymore.
It’s not necessarily laziness. They just don’t care about your request. “This thing you’re asking for is not important compared to the other things I need do.”
I used to run build call and this was the bane of my existence. People who just never engage (but pretend they are to get you to go away).
Fair question. It might be internal jargon. Refers to making a go/no-go “call” on the quality/readiness of a new build.
e.g. A new release candidate is built and tested from a commit. Some tests fail and each test failure is blocking unless the product area owner (or test owner) attests that the issue is not a blocker (test flakiness, test environment specific issue, extremely low priority bug, etc). The build can release only when all test blockers are closed out.
Most build call processes I’ve seen burn more time investigating flaky tests than real issues and the person running build call (often the “release driver”) typically wastes significant time flogging people to close out the same flaky bugs from the last build. I strongly recommend not building one if you can avoid it.
I too would like to know concretely what sort of industry or scenario you are involved in, because in general “it’s simpler to roll your own than use mature, industry standard tooling” is bad advice. “Just build your own index with another table” is either hyper-specific to a niche scenario or flat out a terrible idea.
As another commenter pointed out, this means if nothing else you pay an extra round trip to the DB. Allowing the DB to own the index moves that computation to the data and eliminate a round trip network cost. In general fetching some data from the DB to tell you what other data to fetch from the same DB is a poor design. SQL exists to solve this exact problem.
There are absolutely scenarios where scale is so large that you need a partition lookup service. But this is different from not using indices.
Local farms are rarely selling directly to grocery stores. They sell to a number of organic/free range/whatever companies like Vital Farms that aggregate from the smaller farmers and sell to grocery stores (or grocery store suppliers).
At least that is my understanding of the way the scale is managed.
It sounds like the exchange consumes bids, not just closed transactions. So these companies were basically publishing fraudulent bids that never completed.
I can’t tell from the article if they were bidding on each others eggs or bidding on other farmers eggs and then canceling.
It sounds very much like this person’s HOA is de facto a municipality. They charge fees instead of taxes, which are essentially indistinguishable in this context.
And his HOA maintains water service and roads. So his point stands. How can the HOA provide these critical functions if they lack capacity to collect fees?
The fact that some HOAs are meddlesome neighbor havens doesn’t mean all of them are. (Though I agree with others here that the roles herein described belong to a municipality.)
I see a domain name as property. Am I allowed to buy a house close to the border? Yes. If they change the law, I don't think it's fair to take the house away from me.
If the EU had a law saying no foreigner could own a house inside the EU, and you bought a house and then renounced your EU citizenship, it would be entirely appropriate that the EU forces you to sell the house or forfeit it.
I don’t set the .EU rules. But if they established that the TLD can be used only by EU citizens (or whatever the exact criteria are), I see no reason they should not enforce that. This doesn’t appear to be a case where they changed the rules. It’s a case where the rules were clear and it’s certainly not the EU’s fault that the registrant no longer meets the retirements.
From the other side, why should the EU allow someone outside the EU to hold onto a domain that a person within the EU might want or benefit from?
"they should enforce their rules" is a pretty pointless statement in a discussion of whether the rules make sense.
They should let people keep it because it was bought under the correct circumstances and it's very disruptive to rip away a domain name while harmless to let a very tiny fraction escape that way.
I disagree that the rules don’t make sense. The fact that the rules are inconvenient for a small set of individuals who registered a EU domain and live in a country that decided to leave the EU does not mean the EU rules are wrong.
> it's very disruptive
Britain leaving the EU was very disruptive. I don’t see why the EU should alter their rules to accommodate British citizens. It doesn’t seem like responsibility of easing the disruption should fall at all to the EU when Britain created the disruption.
Why should it apply to anyone that leaves? You haven’t justified that assertion.
If the intent is specifically to have a TLD for citizens and entities within the government’s scope, why should anyone outside that scope get to keep a domain? That is directly contradictory to the intent.
Governmental TLD’s are not supposed to be vanity domains that anyone can grab. That’s not the point.
You got that line backwards. I'm saying that a group/company that wants an EU domain only needs one person in the EU. The standards are very low, not something that gains a benefit from strict enforcement.
You don't really own the domain name though, you rent it from the registar for a fixed term during which you can trade it if you so desire. But it is not something you own, it is a rental with conditions and it can always be taken away. Not saying its fair or not but that's what it fundamentally is and doesn't really map to a fully owned asset.
Is it inappropriate? Not really. Is it a threat? Yeah, it really is. “I’m going to stop using your software if you don’t change this” is a threat. “I’m going to fork it and ship a competing product” is a stronger threat.
It was a clear attempt to sway with intimidation. It was done politely but that doesn’t change what it was. (The dev had already closed as won’t fix, too, so they had preemptively answered.)
“hey, X is a dealbreaker for me, if this is not fixed please let me know so I can look for someone else”
“how dare you threaten me?”
I understand how one might feel attacked by an ultimatum, but a policy of rejecting ultimatums altogether only has the benefit of keeping pride intact, on the other hand it discourages people in your life from giving you a last chance, from communicating why they are leaving, and for letting them come back if the parting was amicable
best response is to just communicate you are not fixing X and parting ways amicably, no hard feelings. not only is it beneficial for the ultimated party, but it’s fair for the ultimating party, who is absolutely in their own right to rescind their voluntary relationship, in no way is it a threat to communicate that possibility, because a threat implies violence or damage.
Again, I did not say the threat in this case was inappropriate. It’s totally legitimate to say “this doesn’t work for me; change it or I’m out”. But it is a threat. We should be honest with what we are doing. If nothing else it makes it easier to understand (and predict) a defensive reaction when we understand and acknowledge a threat is being delivered.
there’s certainly an ambiguety in the word threat, where the main definition is about violent coercion, but it is sometimes used as a useful metaphoric shorthand.
and it’s very common for the usage to cause conflict, the exchange of “are you threatening me?” “no, i’m just telling you what I’ll do” is very common.
i personally wouldn’t use it as a shorthand when there’s no violence or punitory damage implied, unless I purposefully wanted to escalate things. it’s a word that refers to violence, so it will harsh the vibes instantly
a key element of coercion (and this is deeply studied in law so there is less subjectivity than regular language) is that the hypothetical presented cause a damage, and then the avoidance of that damage is traded for a positive action. it doesn’t really apply to a case where a person exercises their right (to leave) and it only secondarily (or not at all) causes a damage, there is no intent to harm and no manipulation of the other into acting one way to avoid that harm.
in the context of leaving a relationship, it might make some sense only if there’s a contract, or even some sense of loyalty that is expected from an extracontractual custom, we are talking marriages or (arguably) employment or religious affiliation, where bonds and codependence are formed. but invoking that treatment for strangers on an as-is warrantyless usage contract? nah
A threat can be violence but it’s not necessarily so. A threat is an expression of a negative result if something is not done. The negative could be violence, monetary loss, embarrassment, end of a relationship, or any other negative.
Definitely not delving into legal definitions of coercion because I am not a lawyer and it is not relevant here.
> and it’s very common for the usage to cause conflict, the exchange of “are you threatening me?” “no, i’m just telling you what I’ll do” is very common.
I think you mean that threats are a common cause of conflict. “Are you threatening me?” “No, I’m merely posing a negative outcome that I will inflict if you don’t do what I want. Totally not a threat. Definitely not.”
So if you're a developer of OSS and released something that _already has inflicted_ a measurable negative outcome for me -- that's okay.
But if I in response say "I don't like, I'm going to fork and use that software without that feature" -- that's a threat to the dev?
I'd say it's very much double standards, especially since in that case the negative action in the original software has already happened and is already negatively impacting the people considering the fork.
And you're saying that them, by wanting to cease it, are the bad guys.
I didn’t say any of that. I did not defend the dev’s stance nor did I say that the statement from the commenter (“change it or we’ll fork”) was unreasonable. In fact my very first comment said it was not an inappropriate statement.
Maybe read the thread before knee-jerk responding.
Maybe engage with the argument instead of knee-jerk rejecting them.
I did read all the comments in this branch and I disagreed with the way you put something.
You didn't "defend" the dev stance but you called someone considering a fork due to the unwanted features "threatening the dev", probably due to the fact it's a negative outcome to them, but somehow you are okay with the dev making the arbitrary decisions that are negatively impacting some users.
You cannot have both. They're either allowed to walk away branching out, or he's not allowed to make "threats" to them.
And you cannot pretend you're engaging with my arguments in the good faith while ignoring clou of my comment and calling it "knee-jerk response" instead, LOL.
Part of the gap in understanding here is that you are insisting on interpreting everything I’ve said in the context your interpretation of the word “threat” rather than the one I have explained repeatedly. This is why you insist on putting words in my mouth, because you are unwilling to accept the ones I’ve actually said.
> You cannot have both.
I can absolutely have both. The dev can make decisions that users don’t agree with. Users can express their willingness to leave or fork in response. And the choice to leave can absolutely be expressed as a threat.
You’re assuming a moral judgement in my statements that is simply not there. This is why I called your response knee jerk. You made an assumption instead of reading what I wrote (and clarified repeatedly).
1. The software will have one less user. (Implication was potentially many fewer given “we” would uninstall.)
2. The software will have one more competing product (forked from their own work).
Most people willing to put their time and energy into building software for others would consider losing users to be a moderate negative and having their work potentially forked and having to compete with a derivative a strong negative.
“We will fork” is a strong threat. It is basically a statement that “we” will fight the maintainer for the effective future of the project. Many open source projects have been eclipsed by their own forks.
>1. The software will have one less user. (Implication was potentially many fewer given “we” would uninstall.)
And what is the injury or harm of that? The developer said they wouldn't action the change and indirectly suggested the user to fork it - "it is open source after all".
>2. The software will have one more competing product (forked from their own work).
This is the very nature of open-source software. Labeling it a "competing product" makes many assumptions that aren't earned. We're talking about a user saying an opt-out feature should be opt-in. If I forked LibreOffice because it contained features I did not like, am I now making a competing product? Am I harming or injuring the repo I forked? Am I fighting the LibreOffice developers?
>Most people willing to put their time and energy into building software for others would consider losing users to be a moderate negative and having their work potentially forked and having to compete with a derivative a strong negative.
The developer didn't seem to consider it a moderate negative.
>“We will fork” is a strong threat. It is basically a statement that “we” will fight the maintainer for the effective future of the project.
You're expanding the scope of what was said. Saying "I will fork your open source software" [to make an opt-out feature, opt-in] is not "fighting" the maintainer for the "future of the project" - it's a core element of open-source software.
Sure. If you don’t care about whether your open source software has users, then there is no harm. People who maintain open source software for free usually do it out if a sense of pride and accomplishment that is tied to how many people use it, though.
> The developer said they wouldn't action the change and indirectly suggested the user to fork it - "it is open source after all".
They said that after the user already threatened to do so. You’re reversing the order. It was not “I recommend this” but “If you’re gonna do it I can’t stop you”.
> If I forked LibreOffice
If all you are doing is cloning the repo in GitHub then sure, you aren’t competing. But LibreOffice is a great example because it is specifically a fork that intended to and succeeded in replacing its parent project.
If someone says “we’re going to fork this because we disagree with your maintenance of the project”, they probably don’t mean “I’m gonna click ‘fork’ on GitHub.”
>Sure. If you don’t care about whether your open source software has users, then there is no harm. People who maintain open source software for free usually do it out if a sense of pride and accomplishment that is tied to how many people use it, though.
Specifically in this case, it seems the developer isn't doing it for free - their work is at least somewhat sponsored and looking at their site it seems to be their full-time work. I'm not diminishing their time and effort, but this isn't someone working late nights that is hoping their software gets its first 100 users.
>They said that after the user already threatened to do so.
There's a button on every public GitHub repo to fork it. If I say "I'm going to hit that button" (even in a particularly rude way) - is that really a threat? It is functionality built into not only the site, but also the culture and code licensing that underpins any open-source project. I struggle to see how anyone could threaten open-source code by saying they'll fork it. Go ahead - that was specifically designed into the license for any reason. It's so prevalent that it has its own button.
>If someone says “we’re going to fork this because we disagree with your maintenance of the project”, they probably don’t mean “I’m gonna click ‘fork’ on GitHub.”
What then is your expectation for what it means? By saying "we're going to fork this software" are they now starting a competing company? Making hardware products using it? Monetizing the pre-existing work? Selling subscriptions?
These are all examples that I read your comment as implying that aren't actually enumerated or described anywhere.
My expectation for someone saying "I don't like how you're running this project and will fork it" is _exactly_ that they'll hit the fork button and make their own project. That's why it's open-source, that's how open-source software works - that's what the button is for. Even if they then went and built an entirely competing business, around one minor change I specifically chose not to make - then what is the issue? The license allows it - and I chose the license.
We’re arguing hypotheticals about what the commenter meant when they said they would fork. I have no evidence they specifically meant that they would create a competitor and you have no evidence that they meant they would quietly fork and change the one thing they cared about. Fork has more than one meaning in this context. (LibreOffice project was forked from OpenOffice.org, while LibreOffice core repo has 983 forks on GitHub.)
I think we can agree to disagree because our assumptions are at odds and we have no data to bridge that gap.
How is "_I really like your software but I the way X is solved bothers me, so I'm going to modify it thanks to your prior permission_" a threat?
"a competing product", perhaps for these pissed with the deb's human skills or those who want to use it in the unique environment he refuses them to adapt them to, contrary to his own licence?
No, seriously, intimidation? "Your position is untenable for us, we'll find another way forward" is a "let's agree to disagree", not more.
Posting the same narrow definition 6 times doesn’t make it true. In one of your many replies you cite dictionary.com. This is the top definition on dictionary.com when I load it:
a declaration of an intention or determination to inflict punishment, injury, etc., in retaliation for, or conditionally upon, some action or course.
This is absolutely not true. If I can’t check in a fix or a feature because someone else isn’t doing the review, it’s definitely still my problem.
reply