On 3/3/20 5:16 AM, Jim Henderson wrote:
On Sun, 01 Mar 2020 17:46:02 +1030, Simon Lees wrote:
Firstly as a simple one we don't publish any form of budget, openSUSE has no legal entity therefore we can't have any assets or money so it makes no sense to publish any form of budget currently. openSUSE has no money, currently it just has an agreement that SUSE will provide all the core things it needs. But this is something we'd like to change with a foundation.
That makes sense to me; the thing that makes this a little confusing for me (at least) is that while we don't have any assets/budget, we do have a treasurer who administers the travel program. That's what made me think of it.
Yes, SUSE allows openSUSE to spend some of its money towards travel support and sponsoring events, so that the board doesn't need to approve every one of these things we created the role of treasurer to approve all the simple ones that clearly meet our rules, they still refer some things to the board if they are unsure.
openSUSE does have a bunch of rules that you could consider bylaws that we follow. All the ones we follow related to the board including elections, removals the community replacing the board etc can be found at [1]. Rules around membership and the membership officials can be found at [2].
If you have feedback on how you think these could be improved that would be much appreciated as these combined with any items we need to add to comply with legal requirements will likely form the basis of the openSUSE Foundations constitution.
1. https://en.opensuse.org/openSUSE:Board_election_rules 2. https://en.opensuse.org/openSUSE:Members
The challenge for me here is the "could consider bylaws" statement - if one goes looking for the bylaws on the wiki, nothing turns up. It's a bit of a case of "this code is self documenting", which particularly when the foundation setup is complete, will be problematic.
Yes agreed, many of these things exist but they are not currently in one nice uniform "constitution" or set of bylaws. This will certainly change and will be prepared before the membership vote to accept the foundation but we will likely wait until we have a better idea of the format needed wherever registering the foundation before we proceed here.
I'll make some time this week to do a little research for specifics, but some things that would appear to be needed include:
1. Policies and procedures for what the board does (ie, scope of responsibility)
This already exists at the following page https://en.opensuse.org/openSUSE:Board The purpose of the openSUSE Board is to lead the overall project. The main tasks for members of the board are: 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
2. Role definitions and responsibilities (esp. for the foundation, I'd probably expect to see chair/vice-chair/treasurer/secretary/... type roles defined with specific responsibilities)
Under the foundation I expect this will change a bit, the amount of paperwork required to comply with local regulations will almost certainly be more then we can expect volunteers to manage so its likely that someone will be employed to manage these roles reporting to the board, but what that actually looks like is still something that is being negotiated with SUSE. More broadly our boards have tended to choose to share roles rather then having one person stick to them. For example we generally rotate who takes minutes for meetings rather then having a secretary taking theme every week. Also given the current unique role of our Chairperson having a vice chair makes little sense as they can't really carry out any of the specific roles that our chairman has as they mostly relate to SUSE vs openSUSE communications. We did struggle a little with this during the recent transition of chairman. Given the unique roll of our Chairperson one thing that has been discussed by some in the past is moving that role to one of "SUSE Liaison" and have no chairperson or at the start of each term the board could decide which elected member should be chair although we have tended to rotate meeting chairing around a bit as well in the past.
3. Some guidelines around project governance and accountability to the membership
This is certainly an area we can improve on, we expect that whichever area we register the foundation in will have further legal requirements in this area and that those will be come the base for improving how we work in this area. Generally each new board has decided where it would like to sit with the level of transparency it provides through minutes since i've been on the board we have tended toward some form of middle ground some previous boards I believe have tried the extremes of a make everything public or not even publish minutes but both of these options have drawbacks so we end up with some form of compromise. Sometimes we have to respect that a company we maybe working with on something isn't ready to make something public, if we were forced to publish details of everything in meetings then such conversations would never happen, similarly in the last 2 years when the board has been dealing with a conflict between two people we tend to just minute that we "helped resolve a conflict" or similar in the minutes so you the community know we are doing something but the privacy of those involved is respected. Beyond those cases we try to make as much public as possible although there has been times in the last 2 years where the discussion around what we do and don't minute takes longer then whatever we were discussing in the first place. There is a final fallback within the board election rules where if 20% of members don't feel the board is doing a good job they can trigger an election of all 5 positions
4. Conflict resolution processes, including both within the membership and within the board
The process for members of the community is / was documented somewhere (we should probably fix this) but essentially the board is the body responsible for dealing with conflict resolution within the project, generally the board will work together with the individuals involved to hopefully come up with a solution that works for everyone or to mediate to get the best possible outcome. Within the board we certainly don't always agree, the difference in ideas ultimately leads to a stronger position and better outcomes for the community, if two members do have a serious conflict then the other members will work to mediate, ultimately the board is a democracy and if we don't all agree on something we vote on it. Board members cannot be removed just because they have a conflict with other members etc so in the end they just have to move on and continue working on whatever comes up.
It also seems that it would be useful to codify who the liaison with SUSE is for various things. For example, if project members have legal questions, infrastructure questions, or other questions that are better answered by our primary sponsor, rather than it being necessary for the membership to track down "the right person" (and I recognize that often times "the right person" is someone involved in the project), having a point of contact who can facilitate getting those introductions made and conversations set up would be beneficial. (The foundation may well reduce the need for that kind of contact as well.)
Beyond resolving conflicts this is one of the other primary roles of the board which goes both ways (sometimes people within SUSE will ask the board for feedback on something they'd like to do in the community). Ot is a key reason for having the chairperson selected by SUSE because ultimately they need to work with SUSE's management on such things.
On a personal note, Simon, I very much appreciate the opportunity to have a respectful conversation about this. Thank you.
Very much agreed, Thank you. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B