Soliciting feedback on a boilerplate template for a POLITICS file for free software projects
cc: @Shamar
https://discourse.qoto.org/t/boilerplate-template-for-politics-md/87?u=jump_spider
Since this isn't nearly as established a convention as some other forms of repo boilerplate, you probably want to briefly describe when I must read this document. For example, I should read a Code of Conduct before interacting with others in your project space, the licence before distributing your code, etc.
I got through your introductory paragraph and thought, "Why do your politics matter to me?" As a user I care about how the software helps me reach my goals, not yours.
While you are obviously free to ignore a POLITICS.txt it's pretty obvious it's a rather short sighted decision, at least from a professional perspective.
For example you might build your software upon a library specifically designed to be broken, just to put shame on developers who don't give a shit about politics! 😉
Another example: suppose you want to integrate #Jehanne into a #Web application. I will refuse your pull request, no matter how many people want it and no matter its quality.
The fact is that when you decide to depend on my work, you decide to depend on my goals. Writing down my political goals I let you know what to expect. You are free to ignore it, but at your own risk.
>While you are obviously free to ignore a POLITICS.txt it's pretty obvious it's a rather short sighted decision, at least from a professional perspective.
The problem is that this *isn't* obvious. The various other files you commonly see - LICENCE.txt, CHANGELOG.txt, CONTRIBUTING.txt, etc. - are relevant to specific audiences, and the rest of the world can safely ignore them. It isn't at all obvious until I've read it whether I can ignore POLITICS.txt (in fact, the first time I read it, I was expecting it to contain warnings about exporting cryptography). That's why I think the introduction should detail who's expected to be familiar with its content.
> For example you might build your software upon a library specifically designed to be broken, just to put shame on developers who don't give a shit about politics!
Only insofar as that's true of *any* documentation. You could equally put your warning in a document called RELIGION.txt to spite developers who don't care about that instead.
> The fact is that when you decide to depend on my work, you decide to depend on my goals. Writing down my political goals I let you know what to expect.
Traditionally, developers let people know what to expect by maintaining a roadmap for the project.
Roadmaps are not political goals.
They talk about what is going to happen to the software, not about what we are trying to achieve through the project.
While I have to admit I'd read carefully a RELIGION.txt to understand how a software is related to religious beliefs, I don't think it's the same.
#Software impacts #society in several ways, while it doesn't impact God, usually.
However there are notable exceptions such as #TempleOS that deserve all of our respect.
Anyway, as I said you are free to ignore the political goals of a project at your own risk, just like you can ignore the license or the code they write.
For example I purposedly ignore #CoC because I refuse to adopt an #US workplace like behavior in my #free time.
If forced to read them I look for ways to ridiculize them by violating their letter without violating their rational. So usually it's better for the project leaders to NOT try to impose me their #moralism.
Yet I do this at my own risk.
