Shedding Light on Management Committee [WAS: Re: [owin] Specify OWIN Security Middleware (#7)]
Ryan Riley
- We need to do better at communicating. To that end, we’ll plan to keep using the mechanisms described above and ensure we post notifications of future votes to the mailing list.
- We appreciate and need your feedback to make sure this works. Please help us refine this governance model so that it is successful for us and the next round of committee members.
- Let’s use this list to discuss how the OWIN governance works (or doesn’t work) rather than dirtying up the issue threads on GitHub. (This is a suggestion; feel free to offer alternatives.)
You mean the Ryan Riley and myself were elected along with one member from Microsoft "to be named later".
Didn't realize Mark had joined Microsoft.
I also didn't realise that those meetings would happen without notice or without a published agenda.
I'm sure it's not on purpose but all this is very opaque from where I stand and I don't like it much.
________________________________
From: Ryan Riley <notifi...@github.com>
Sent: 29 July 2014 19:25
To: owin/owin
Cc: Sebastien Lambla
Subject: Re: [owin] Specify OWIN Security Middleware (#7)
You can find minutes from our meetings in the wiki<https://github.com/owin/owin/wiki/Management-Committee-Meetings>. List of members is posted on the OWIN homepage<http://owin.org/>.
-
Reply to this email directly or view it on GitHub<https://github.com/owin/owin/issues/7#issuecomment-50517377>.—
Reply to this email directly or view it on GitHub.
Sebastien Lambla
Thanks for this constructive reply. It's nice when things don't go down ad hominem. I wish people didn't question my motives every single time. I pick up fights when I believe they need to be picked up, even if it brushes the wrong people. You may not like
my style, but questioning my motives or trying to ridicule my principles by attributing it to ego is very annoying, even more so for those of you that know me and have met me. Clear up over, let's focus on the issue at hand and leave egos at the door shall
we?
So my concern was around "Following up after this week's committee meeting, I'm going
to pick this up when I have time.".
My understanding here is that the role of the management committee is:
"Beyond the responsibility of merging contributions, committers as a group (called the Management Committee) participate in strategic planning,
release planning, and approving changes to the governance model. The management committee also makes decisions on patches when community consensus cannot be reached. The management committee has final say over who can become a committer and will use lazy consensus
for approval. Discussion over committer nominations will be done in private."
Picking up a piece of work is an amazing thing that I'm very happy to see happen, and I'm sure that it is all one big miscommunication, but I am under the understanding that discussions about who picks up what work to push the standard forward has been and
ought to be on this mailing list with the committers and follow the rules that were agreed upon in the governance model.
That's where the lack of visibility of what is going on in those meetings is a concern to me.
That's why I wanted those clarifications, thank you for providing them. Thanks to Mark for offering his personal help in pushing those items forward.
This said, those items as I understand them are not administrative, as they are still under discussion. If "picking things up" meant "put to a vote" then that is within the committee's responsibility. If it is "needs work to write the spec" or "needs a
push to get further" then that is within this group's responsibility, which the committee is part of, and those conversations belong with this group and not the committee.
The distinction is subtile, and I realise a lot of people are gonna be brushed off that I'm criticising and frustrating them in what is a genuine effort to help. I assure you all that I love you all with all my heart, but this is a question of separation of powers that needs to be taken very seriously when having a governance model.
The delivery of the message is as important as the message itself.
I don't want anyone to be alienated, but where communication gaps exist they ought to be addressed. In this spirit, here's a list of concrete steps the management committee, and us as the wider owin community, can take
to avoid those issues.
- Minutes to be linked from the owin site in the organisation site
- Meetings of the committee to be specifically adressing the points the committee is responsible for, and nothing else, and make sure the minutes reflect this
- Specify in advance the points the committee has to work on so any meeting (adhoc or not) is covering items that everyone is aware of (see how the W3C does it with their weekly calls ought to be a good guidance)
- Clarify who are committers, I'm not sure we have a list
- Discussions about pushing forward work items to be had either through this mailing list, or on concrete proposals through github issues, with biscuits provided with the contributors, whoever they may end up being
- Regular conversations may sometimes require skype calls between interested parties. While informal, they tend to allow for crystallisation of opinions. It has happened a few times in person in conferences. Putting some structure in the spirit of openness and transparency around those discussions would allow the group to continue functioning without stuff happening away from anyone's ears. I've probably been very guilty of that in the past, I'd rather it was out in the open.
Sent: 30 July 2014 14:52
To: net-http-a...@googlegroups.com
Cc: Sebastien Lambla
Subject: Shedding Light on Management Committee [WAS: Re: [owin] Specify OWIN Security Middleware (#7)]
You received this message because you are subscribed to the Google Groups ".NET HTTP Abstractions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-http-abstrac...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Ryan Riley
Ryan Riley
Sebastien Lambla
Ah of course. Completely missed the part that calls committers as a group the "management committee". That clarifies things a bit.
This is not helped by the decision making process that specifies:
these are the committers and/or the members of the Management Committee.
This is not the only place where a distinction was made between the PMC and the committers, as the rules are different between voting for a new committer (which is approved by consensus of the PMC) and a new PMC member (which is approved by consensus of
the community). As the original election process did not see any -1 for anyone expressed on the list, as per my reading of the voting procedure, all nominated people ought to have been (or are, in effect), a PMC. I think we may have a constitutional crisis
there.
This is even more confusing when we continue on that document that specifies:
Such discussion will continue until the objection is either rescinded, overruled (in the case of a non-binding veto) or the proposal itself is altered in order to achieve consensus (possibly by withdrawing it altogether). In the rare circumstance that consensus cannot be achieved, the PMC will decide the forward course of action.
So the PMC can overrule a -1 from anyone, or people can just agree, or the PMC can decide what it wants? That's how I read it, I'm not sure I understand the original intent, it seems unclear.
So let me try and clarify by speaking out loud.
- all votes by anyone are non binding
- PMC (aka committers) have binding votes
- a -1 from a community member (aka everyone except committers), called an objection, is to be addressed by the community as a whole, leading to either the withdrawing of the -1, a [consensus], or overruling by the PMC
- a -1 from the PMC is a veto, for which there are no rules to rescind
- lazy consensus is no one says -1 in 72 hours after the beginning of a vote
Now to make matters even more confusing in my head, we have many consensii
- community consensus, undefined (maybe lazy, maybe full consensus, but how does one know when a consensus is reached? Ask everyone on the ml to vote?)
- lazy consensus, as defined upwards, no vetos, but maybe overruled objections
- consensus of the management committee (undefined, same as community)
- unanimous consensus (referred to for both community and PMC) - no definition
Finally, the distinction between Users and Contributors (as opposed to committers) is impossible to do, as there is no contributor assignment in place with any set of criteria. And it also really doesn't matter, because neither users nor contributors are
mentioned anywhere else except to give them names, so their position in governance is completely irrelevant (and a lack of contributor license agreement or copyright assignment prevents that distinction from making any sense).
I know we're opening a can of worms, but there are some serious flaws in those texts and giving this much power in the future of owin to a constitutional text that is so inadequate causes me issues and I want it fixed.
Those at monkeyspace will remember that I've been very clear about my will to have a strong framework in which all rights are balanced and a fair process exist. I don't think this exists as it stands. My issue is not in the current members, but in creating
a group that will survive those members and make owin an awesome platform. As such, while I respect all of you, you may all tomorrow change, and texts of governance ought to address this.
Standards are no place for benevolent dictatorship, this is not open source software, and those texts are dangerous left in the wrong hands.
Lets address the shortcomings in current communication, address the fact that the committers title is currently inapplicable as I understand it, and then address the fact that the texts are unclear if not simply impossible to apply.
Sorry to jump in the mud, but I have a feeling that I'm being sent in a corner with a tap on the back and I don't know it's getting us to our common goal.
To: net-http-a...@googlegroups.com
Subject: Re: Shedding Light on Management Committee [WAS: Re: [owin] Specify OWIN Security Middleware (#7)]
Mark Rendle
Sebastien Lambla
Also, no idea why I just called it the PMC, suppose the MC name was a bit too hip.
Sent: 30 July 2014 21:19
To: net-http-a...@googlegroups.com
Subject: RE: Shedding Light on Management Committee [WAS: Re: [owin] Specify OWIN Security Middleware (#7)]
Sebastien Lambla
The point I was raising is not that you would, but that the document entitles you or any other members to, and I'd rather see that fixed.
Sent: 30 July 2014 21:50
Mark Rendle
Mark Rendle
Ryan Riley
> absent a Microsoft rep (since they seem more intent on supporting interop between their own thing and OWIN, rather than writing their own stuff to run on the OWIN standard) it's ended up with Scott K, Ryan and me.
Ryan
scott...@gmail.com
Members of the PMC do not have significant authority over other members of the community, although it is the PMC that votes on new committers. It also makes decisions when community consensus cannot be reached. In addition, the PMC has access to the project’s private mailing list and its archives. This list is used for sensitive issues, such as votes for new committers and legal matters that cannot be discussed in public. It is never used for project management or planning.
Beyond the responsibility of merging contributions, committers as a group (called the Management Committee) participate in strategic planning, release planning, and approving changes to the governance model. The management committee also makes decisions on patches when community consensus cannot be reached. The management committee has final say over who can become a committer and will use lazy consensus for approval. Discussion over committer nominations will be done in private.
On Wednesday, July 30, 2014 1:58:47 PM UTC-7, SerialSeb wrote:
The point I was raising is not that you would, but that the document entitles you or any other members to, and I'd rather see that fixed.
From: net-http-abstractions@googlegroups.com <net-http-abstractions@googlegroups.com> on behalf of Mark Rendle <ma...@markrendle.net>
Sent: 30 July 2014 21:50
Subject: Re: Shedding Light on Management Committee [WAS: Re: [owin] Specify OWIN Security Middleware (#7)]
I think it's clear there are issues with what is written down regarding the role of the committee, and where there is room for clarification we should probably make the effort to clarify.
The fact is that with a community-driven effort like this, some part of that community needs must take the role of starting the voting process, tallying the results and overseeing the translation of those democratic decisions into specifications, documents or further discussion.
There is, for OWIN, no obvious BDFL, so raising a single individual to that role would be unsettling (not least for that individual). So a small committee was seen as the best approach. Two would have been a strange number (can't use the word "odd" there), too many would have made successful convening of meetings even more difficult than it already is, so three people it is, and absent a Microsoft rep (since they seem more intent on supporting interop between their own thing and OWIN, rather than writing their own stuff to run on the OWIN standard) it's ended up with Scott K, Ryan and me.
I am not aware that the committee has any extraordinary powers (apart from Scott's Green Lantern ring); there is a responsibility to push things forward and, if necessary, to resolve stalemates, but thus far, discussions have run their course in the public fora and been resolved, if not to everyone's complete satisfaction, at least in an amicable fashion.
Point is, nothing is going to get forced through by us three against the express wishes of the rest of the community; if we tried to do that, it would simply result in some sort of schism anyway.
If we can write this down in a way that makes it explicit rather than tacit, then let's do that as soon as possible.
Cheers,
From: net-http-abstractions@googlegroups.com <net-http-abstractions@googlegroups.com> on behalf of Ryan Riley <ryan....@panesofglass.org>
Sent: 30 July 2014 20:08
From: net-http-abstractions@googlegroups.com <net-http-abstractions@googlegroups.com> on behalf of Ryan Riley <ryan....@panesofglass.org>
Sent: 30 July 2014 14:52
To unsubscribe from this group and stop receiving emails from it, send an email to net-http-abstractions+unsub...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups ".NET HTTP Abstractions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-http-abstractions+unsub...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups ".NET HTTP Abstractions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-http-abstractions+unsub...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups ".NET HTTP Abstractions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-http-abstractions+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups ".NET HTTP Abstractions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-http-abstractions+unsub...@googlegroups.com.
Sebastien Lambla
>
> The documents are based on the Meritocratic governance model put forth by OSSWatch out of Oxford. They are copied pretty much verbatim, with some changes in terms or omissions of references to "source code", since we don't really have any source code.
Either owin is a repository of standards that have a process to be published (review, editor in charge of the changes, independent implementations that interop) and only host such specs, a la RFC, and you do not need consensus at all, or it is the core owin spec, where independent but breaking changes will damage intro and the brand, and then it is for that group to be the last resort to refuse or reject such proposals in the case the community at large (and hence not a consensus) rejects that option.
Either way, neither models fit with the OSS dictatorship model.
I think calling people committers when we only talk about prose and interop and standards is muddying the water and has nothing to do with what we do.
Now there is a very big difference: in standard groups, the members of each working group are the ones delivering the edits and doing the work, and the binding votes are only useful when deciding a standard is recognised as a standard, which in our case we have no process for. And the people with the binding votes are not necessarily involved in the process of designing or building the software.
Benevolent administration (such as what an editor does in a typical working group) is a different thing from benevolent dictatorship from people accepting edits. In those models, the managers of OSS usually are the main contributors. The balance of power is fundamentally different.
> We did discuss during the initial call (I think, I know we discussed en masse at some point), limiting the number of members on the MC that a single organization could have to prevent the spec changing to match any one vendors agenda. Not just Microsoft, but any vendor. One could see an MC comprised of a majority of members working for a single component vendor adding vendor specific keys to the spec.But I don't think we documented that thinking anywhere.
> In any case, should we require unanimous agreement to move the spec forward? Or should we require a majority vote from the committee to override community votes, vetoes, etc…
That’s an interesting question, I’ve not formed an opinion yet, because it’s asking for the wrong question. I argued before that I was only agreeing was an individual to the terms of the “governance” so that people with the power to change that governance to something that is suitable could do so, I could dig the email but it’s late.
So as far as i know, it’s the whole document that needs rewriting from the ground up.
> I'm not trying to make it binary, I'm open to nuances.Just trying to put it into small words I can understand.
> I'm still waiting for my complimentary MC member Bentley automobile. I called the local dealer and they just told me something about a duck off? I don't know what a duck off is? Some kind of waterfowl competition?
Seb
Sebastien Lambla
People tend to read between the lines when I write and I’d rather try and be more precise. Language barrier and all that.
—
Sebastien Lambla
http://serialseb.com