On Thu, 21 Feb 2019 at 11:01, Lars Vogdt
openSUSE membership can be managed via paper. Setting up Email aliases and IRC cloaks can be stopped until there is a new tool established. Lost trust and data because of security breaches is way harder to restore and will result in much more work for everyone.
I wholeheartedly agree, which is why the recent changes to the process and requirements for new "tooling" written as loosely as they were. (pen and paper is a "tool") We took great care to make sure the door is wide open for innovative solutions to the problem. But, the problem should not be exacerbated by the actions of other contributors. That's simple good behaviour under our Guiding Principles. To give an equivalent example. Badly maintained package gets removed from our distributions. In these cases, the maintainer is expected to drive forward the situation, meaning the maintainer is expected to announce the intention of removing the package, the maintainer is expected to drive the mitigation of the removal of the package. That might mean talking to others and encouraging them to take on the problem, that might mean posting general calls for help on the mailinglists. I think those expectations carry out to situations like this just as well. Like a key package in our distributions, connect.o.o provides a key service upon which the entire governance structure of this Project is built upon. If people in the community want to shut connect.o.o down, the idea should be entertained, but the people wishing that need to drive the solution. I think there is no suggestion that such an idea isn't justified. But despite the justification, the implications need to be considered also (like those I've stated in this thread) Those wishing to shut down connect.o.o need to propose and be prepared to implement a replacement that mitigates those implications, be those technical, pen or paper, or pidgeon based. As we're talking about changes to the Governance structure, any such changes need to be done with the consent of the project as a whole. Our rules would require such constitutional changes to either be executed after a Membership Vote on any proposals, or we do have provision in the rules for the Board to decide on such topics if they have a 2/3rd majority. We can't just have people randomly turning off services which provide key planks to the project. If OBS dissapeared tomorrow without replacement we wouldn't have any distributions. If connect.opensuse.org disappears tomorrow we don't have any Project members. Quite often, when other topics with a Project-wide impact but no clear owner, such things end up on the Board's desk, as the escalation point of last resort. But we're talking about the very process which selects who can vote for the Board. I think that provides an ethical conflict of interest that should disqualify the Board from having a leading role in driving a solution to this problem. The Board shouldn't be in a position to define the pool which can vote for it. That undermines the whole concept of the Board being answerable to the Membership. This is why the Board's changes to the Membership process to date were a compromise - we reworded things to make alternative processes to connect.o.o a possibility, but it would be egregious if the Board redefined the process in a material way that impacted the Membership significantly without the consent of the Project as a whole. The Membership is meant to be a body representative of the project as a whole, therefore I feel this problem is something best handled by the Project as a whole, so this is a good discussion to have right here. This isn't the first time I've asked this question on a public stage, but in the hope that this time I get an answer; Who volunteers to tackle the problem with connect.o.o and drive forward a solution? -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org