On Tue, 03 Mar 2020 12:00:47 +1030, Simon Lees wrote:
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.
That makes sense, thanks for clarifying.
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.
That's good to hear.
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
That's a good general statement for what the board does. Some broad guidelines about the 'how' for these items would be a good addition (some of the 'how' is self-evident - like "facilitate decision making processes where needed" doesn't really need to be spelled out, I don't think - but "communicate community interests to SUSE" might - identifying who the points of contact are, for example, might be a good thing to spell out. That would provide some ability for oversight and clarity on the various roles; for example, on questions around use of branding/logos, that would be a contact in SUSE's legal department, but spelling out the limitations of when to contact SUSE IT for shared infrastructure questions might be something that's less clear).
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.
That makes sense to me.
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.
That makes sense, but would be good to have that spelled out - that's not something I (at least) was aware of in how the board operates. Not having a single point of contact (beyond "board@o.o") for questions means that it's perhaps not as predictable as it should be who takes the minutes, the format (potentially), etc.
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.
That's an interesting idea, though a rotating chair would also raise (for me) concerns about predictability. Not everyone is as good at facilitating meetings as others (for example). While we may not be looking to structure a board "in order to scale up", a lot of the same ideas that are used in putting corporate governance together still apply. If the role currently identified as the 'chairperson' shifted the way you suggested, I could see, as a member, wanting to consider different people for different roles; someone with a finance background for treasurer, someone who keeps impeccable minutes for secretary, someone with good leadership abilities as chair. Rotating those roles means that we'd need to find people with all of those qualities because they could be picking up any of those things - and that also muddies the waters around accountability.
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.
That makes sense to me.
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.
I can appreciate that there's a balance to be achieved, and that such balance is likely to leave some unsatisfied with the result. As an open- source community, erring on the side of transparency is an easy thing to *say*. As I noted previously, our values include not just treating each other with respect, but also with being transparent and open. We don't ship proprietary stuff with our distribution because we value "open" so highly that it causes some issues for new users who are wanting to have proprietary codecs included (or video drivers) for ease-of-use. But we have (I think rightly) held to the value of "open" very strongly, and we have some excellent guides to help new users make their choices accordingly. Following in that vein, it should perhaps be codified that we are "transparent/open" by default unless there is a compelling reason (with some guidelines spelled out in the interest of clarity) so there isn't an appearance of "we didn't want to air this publicly, so we decided not to". I'm not saying there's a history of that (it'd be hard to judge without knowing specifically what hasn't been shared), but that providing those guidelines gives the membership something to understand what sort of criteria are used.
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
Which is a necessary thing to document, but unlikely really ever to be triggered. I've watched a few boards (not related to open source at all) completely implode even recently, and a big part of the reason was the idea that "everyone knows how we operate, so we don't need to write it down in any sort of detail". One board (which shall remain nameless) had codified that only the chair could talk to the external counsel they retained, and there ended up being an ethics problem that came up during/ after a recall vote that resulted in the chair resigning. The fact that this particular board had actually codified the rules meant that there was accountability, and the membership actually was able to hold the board accountable (about half of the board resigned as a result). I'm not saying that the openSUSE board would ever be in this position - I would never *want* to see that happen. But I think we're on the same page about the need to document it in case something comes up where an audit is necessary (and clearly if/when the foundation is set up, there are legal reasons to need that anyways).
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.
That makes sense. I've used the mediation process myself (as one of the admins in the forums), but at the time it was more "I know someone on the board, so I'll ask for help". Not everyone has those relationships with individuals on the board that they can tap into when a situation arises.
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.
Arguably, there are some lessons to be learned from the recent situation - I won't rehash that now out of respect for all involved. Hopefully with some time/distance, an objective evaluation can be performed to figure out what could be done better the next time a situation like that one arises.
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.
I have always felt this to be the case, so it's good to know that I'm not alone in thinking that's one of the primary purposes of having the chair be someone from SUSE. -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org