On Mon, 21 Mar 2022 21:01:16 +0100, Axel Braun wrote:
But I also see the point that [Simon] and Richard are making about the board's role here. I do think this is something that is bigger than the project, but the project's voice in this matter could be important, so a vote on an adjustment to the role and vision would seem appropriate to me.
I'm open to discuss adjustment of roles, but I feel in this case there is no need to: how are we supposed to advocate for openSUSE Linux if we can't advocate for policy that furthers that goal? The goal is clearly wider than just 'our' distribution, but it should not stop us from taking appropriate action.
So, from Richard's list of things the board is tasked with, I don't see advocacy of openSUSE Linux as a part of that list
(The list, for convenience, taken from Richard's initial response)
- Act as a central point of contact - Help resolve conflicts - Communicate community interests to SUSE - Facilitate communication with all areas of the community - Facilitate decision making processes where needed. - Initiate discussions about new project wide initiatives
It seems that the last item on this list is where this would fit IMO, and this thread achieves that goal.
From there, the thing that should happen is a community discussion about how (and if) the project membership as a whole wants to pursue this project. If the membership wants the board to take it on, that's something for the members to decide, not for the board to decide on its own - at least based on my understanding of how the board is intended to operate.
One of the real challenges that we face is things like TPM and other such proprietary technologies that restrict user choice in operating system software choices. Championing user choice is something that, to me, would be appropriate for the project to do (whether it's the board doing it or a group of interested members doing it). Something like restricted choice in operating system selection in consumer hardware would seem to me to be a fight (or discussion) worth having.
True. TPM can be the trojan horse to lock free software out, if hardware comes in conjunction with proprietary protocols and systems. One more reason to protect users from preinstalled proprietary systems....
I'm absolutely not disagreeing with this (clearly). Just agreeing with Richard that this falls outside the board's purview as things stand today. That can be changed by the membership, but the membership needs to be involved in any expansion of the boards responsibility and authority - if only to ensure that a future board doesn't decide to unilaterally just assume more significant "power" over the project that it shouldn't have.
That's the reason we have documents that describe the board's authority and responsibilities. They're not written in stone, but they can't be changed by the board without membership consent - that power isn't explicitly granted to the board.