It's part of my job to "railroad" potential majorities that would prefer to do things that my judgment suggests will make things worse.
They're free to do it in their personal trees all they want. But if they commit changes that make the code less readable because some tool is being opinionated and can't be configured properly, their change won't pass code review.
Sure, but that's why I mentioned politics -- the particulars matter and there is plenty of ground for reasonable people to disagree.
Judgement goes both ways. Maintainers are under no obligation to accept my code, but if enough maintainers stonewall enough of my code for reasons that I consider unreasonable enough then I'm under no obligation to write the code, either. That's where I've gotten to. It wasn't a short journey. Oh well.
I mean users because I think it's important that people who receive my code can inspect it, especially if a third party has changed it between me and them. I also think they should be able to make their own changes.
You're right, very few care, but it's an important software freedom. Apathy doesn't mean freedom is bad.
And being overruled by the people actually maintaining the project. In other words, you have the people actually writing the code saying something doesn't belong, and someone who isn't really involved in the project saying "no, we must keep this offensive thing".
It's literally an outsider trying to force the actual maintainers to do something they disgaree with. But you appear to support the outsider.
sorry. i was not clear. i just meant to say that one need not agree or disagree with it in order to gain some value from it.
i mean, it's worth thinking about: "some people might get mad when i make a change to this unfamiliar, problematic, buggy code base. but how mad are they going to be? could my boss become angry with me? will i make any enemies? will i be a hero? will anyone even notice?"
If people were interested in stopping the bikeshedding, they would create an editor that let everyone view the code however they please, and check in with a consistent format that doesn't matter. Extensions for source control tools and debuggers would quickly point to the token that caused an issue, for example, rather than the line number.
Instead everyone just creates rules that they like, then force those rules on everyone else as a power move, then use "this is for consistency and anti-bikeshedding" as an excuse to keep their own preferences enforced on others.
And before anyone argues, I've seen it happen multiple times. I swear people become team leads solely to force their preferences on others. They certainly are fond of power trips, in my experience.
I just don't think this makes its case well, though there is a case to be made.
I have worked at places where one person should never have the ability to push unreviewed code into master because the company was huge and already successful and it'd be a security risk.
I have also worked with coworkers who fetishized the process part of stuff and wanted to create all sorts of rules with high overhead to solve entirely hypothetical problems from their imagination.
That article says you have the right to frame the discussion about what other people can and can't do with your code. Other people can't dictate what you promise them, but it's reasonable for them to expect you to be consistent about it.
I really don't like the sentiment of "We shouldn't change it unless the man page says we can". That's exactly the kind of senseless bureaucracy that the open source community should be avoiding.
You shouldn't ask permission for it because on most of the time you shouldn't be doing it. It's like going to the grocery store hungry, without a shopping list.
I'm a big believer in:
1. You don't modify code without intent to change it's behavior. You're there to fix a bug, or add a feature.
2. You leave the code you better than you found it. In fact, you elevate it to your/the-team's standards du jour.
3. That's the cost of doing business. There are no multiple estimates. It's not "Well, an hour to just fix it with a hack but it really deserves a day". That's a day. Deciding on the team's values and coding standards is a group-decision. Deciding on when to apply them isn't.
With regard to the first point, the examples may be hypothetical, but they are also very plausible.
When a change has little or no objective benefit, I feel the burden of demonstrating that it is harmless falls on those making the change.
As has been pointed out elsewhere, this is free software and the maintainers are free to do whatever they like. That does not stop others having an opinion about it, especially when it is in the form of constructive criticism.
I don't like the convention where I have to decide whether or not something I write is suitable for other people. They should read the code and decide for themselves.
That's easier said than done, kudos to those that pull that off but there is this thing called code review and if your co-workers are halfway competent you'll get called on what you built. In some cases that can be a career limiting move.
And so it should be. We're talking about a technological measure that is being implemented with the intent of preventing an actual crime. There is a real possibility in this case that undermining the measure will increase the amount of that type of crime that is committed. There is also little evidence that the measure is being abused by others on a significant scale with actual negative side effects for anyone.
Now, a developer might not want to implement that measure because they were concerned with other consequences that might not be in the public interest, or with the future potential for such consequences. This might be a perfectly reasonable position morally and/or technically, and as you say, that developer has the choice not to take that job. It's not as if good programmers are starving in the streets for lack of other opportunities, after all.
But if you do take a job as a programmer on a project, typically your authority and responsibility do not extend to setting the requirements and deciding on policies like this. If you presume to deliberately undermine those whose jobs do include making those decisions, you should be treated as a bad employee and dealt with accordingly, and that does include being fired, getting a professional reputation for being unreliable and not a team player, and so on.
If you're a good politician, that may help you push the right buttons - but unless you can show concrete business damage because of the choices made, you are still likely on the nasty end of the stick. Nobody cares whether the developers are happy with the code - they care whether the code solves their problem or not.
It's not a valid argument that everyone should bend to your whim, it's possible a valid argument that (a) there should be a load of config options and/or (b) you should be able to edit the source code to make it work how you want.
They're free to do it in their personal trees all they want. But if they commit changes that make the code less readable because some tool is being opinionated and can't be configured properly, their change won't pass code review.
reply