[ciphershed] Re: Transparency
- From: "Alain Forget" <aforget@xxxxxxx>
- To: <ciphershed@xxxxxxxxxxxxx>
- Date: Tue, 17 Jun 2014 08:40:25 -0400
Excellent points. So this is forking into two (somewhat related) discussions
which perhaps should be considered separately: What policy we should adopt for
relations with external parties (which I'll call "public relations" for
simplicity), and our decision-making process going forward (which is what the
Apache model mostly covers).
Regarding public relations (PR), if we don't chose to institute a PMC identical
to the Apache model (who I suppose I'd assumed at least a subset of which will
also be the PR people), then I definitely agree with Niklas that, " [...] the
PR people can only speak for their understanding of the group, not for the
group itself. Nor can they take any decisions concerning the project on their
own." However, to be clear, if we do go with an Apache-identical PMC, then by
definition, they *do* make decisions concerning the project on their own,
because they were elected to do so.
Addressing our decision-making, I agree with Niklas that consensus-based
decision-making has been working out fabulously for us thus far. My concern
with our decision-making is perhaps longer-term; as our community grows and
more people get involved, there are some things that remain unclear to me:
1) Should some people who have been involved and contributed more to the
project be (explicitly) be given more weight to their voices? This has inherent
pros (they are trusted and are perhaps more like to "stay the course" of the
project's vision and goals) and cons (fresher perspectives from newer are given
lower value, perhaps undeservedly, and this may create some form of "elitism"
in the older community members). If this is something we want, should we simply
try to keep this organic, or should we explicitly elect and publish said
persons into a PMC?
2) Since anyone can join the IRC and public mailing list, it is (perhaps?)
inevitable that there will be some people who will join that will certainly
offer opinions and perspectives, but these may turn out to be more destructive
than constructive. Even in these early days, there have already been some of
this (although fortunately not yet on this mailing list). With a PMC, the
developer and wider community can elect decision-makers to the PMC that they
trust to represent their interests, so that developers can focus on what they
want to do without having to worry/be distracted with every little wider issue
that comes up, and the PMC is less likely to be distracted by destructive
personalities (who I am assuming are very unlikely to be sufficiently supported
to be voted into the PMC). We would need to closely iron out details to ensure
the necessary accountability so that the PMC doesn't become some group-thinky
"old boys' club".
3) Regarding Niklas' comment, "I don't think this discussion should be viewed
as something bad
or annoying," I wholeheartedly agree (and I see these as crucial and
fascinating discussions). However, if there are some (many) members of the
community who *do* find this discussion bad and annoying, then I may consider
that an excellent reason we should form a PMC, so that said people can be
spared these kind of organisational-type discussions, and those of us who value
them may continue without bothering the other valuable members of the community.
These points, in addition to Niklas' other points (avoiding paralysis in
consensus-based decision-making vs. Apache-PMC decision-making) are to consider
and definitely discuss. However, I feel that it would be easier to build an
Apache-PMC now, before there is some largely divisive issue, than remain
consensus-based until we get paralysed and then feel we "need" a PMC, since at
this point, I fear the PMC will be much more difficult to form and its forming
will be largely muddied by the largely divisive/paralysing issue. I fear it
would be a huge mess and biased-process to build a PMC under those
circumstances.
Alain
-----Original Message-----
From: ciphershed-bounce@xxxxxxxxxxxxx [mailto:ciphershed-bounce@xxxxxxxxxxxxx]
On Behalf Of Niklas Lemcke - ???
Sent: Monday, June 16, 2014 23:11
To: ciphershed@xxxxxxxxxxxxx
Subject: [ciphershed] Re: Transparency
I disagree with PID0 in that I believe that a consensus-based decision
process will not paralyse the project. In fact I believe that deciding
to use a vote-based decision process would be more likely to cripple
it.
When there is a 2vs3 voting situation, there is an obvious need for
more discussion. We have clearly stated objectives, that are widely
accepted among all of us. We worked with a consensus process so
far, and it worked very well. I believe that the vote-based process
would only encourage a majority to push a decision through because
there's a majority, not because they have the better arguments. This
project survives on every members commitment and open-mindedness. A
system with a hirarchy (elected personell to take decisions) or a vote-based
decision process would annihilate those two things.
Also, The Apache projects are "managed using a collaborative,
consensus-based process. We do not have a hierarchical structure.
Rather, different groups of contributors have different rights and
responsibilities in the organization." They haven't been paralyzed so far.
Their approach seems nice. While I would like to keep things lose, I
believe I could arrange with that, and with 2-3 PR people being
appointed. Basically we're already having something similar, with only
three people having write-access to the git repo.
It should still be clear though, that the PR people can only speak for
their understanding of the group, not for the group itself. Nor can
they take any decisions concerning the project on their own. I believe
that is obvious.
As a last point, I would like to remind everyone participating in the
discussion that--although it may be tempting at times--polemics are
neither going to solve the discussion, nor do any good to it. We should
stay as objective and mature we can manage to.
Also, I don't think this discussion should be viewed as something bad
or annoying. These are common, very important discussions that neet to
take place to establish a consensus among the project members on how to
operate. Thus I want to explicitly invite anyone fostering an opinion on
the topic to comment. :)
Niklas
On Mon, 16 Jun 2014 15:00:49 -0400
"Alain Forget" <aforget@xxxxxxx> wrote:
> An Apache-style Project Management Committee (PMC) sounds sufficiently close
> (but broader in scope) to what I was proposing for option B. Clearly, we
> don't have a "Board", as Apache does, but I can see how a PMC might work well
> for us.
>
> The concepts in the Roles section seem to apply very well to us (aside from
> "ASF Member", because we're not a part of Apache):
> https://www.apache.org/foundation/how-it-works.html#roles
>
> I think many of the other concepts on that page would work well for us.
> Basically, by adopting a similar model, we're benefiting from their
> significant experience.
>
> At this point, I support this concept. Closely following the Roles, I'm
> envisioning some subset of us would be on this PMC. Anyone who is currently a
> core contributor, but is not on the PMC would be Developer by default, and
> then the PMC could elect any of them to be a Committer. However, the Apache
> pages seem to omit how they advise seeding (initially forming) a PMC, so I'm
> not sure what the best (and fairest?) practice would be. If we're all on the
> PMC, wouldn't that kind of defeat the purpose?
>
> How do others feel about instituting a PMC?
>
> Alain
>
> -----Original Message-----
> From: ciphershed-bounce@xxxxxxxxxxxxx
> [mailto:ciphershed-bounce@xxxxxxxxxxxxx] On Behalf Of Jason Pyeron
> Sent: Monday, June 16, 2014 14:32
> To: ciphershed@xxxxxxxxxxxxx
> Subject: [ciphershed] Re: Transparency
>
> > -----Original Message-----
> > From: PID0
> > Sent: Monday, June 16, 2014 14:23
> >
> > Design by committee is going to paralyse this project the first time a
> > single person on the mailing list disagrees with on a
> > particular issue.
>
> Quoting: http://www.apache.org/foundation/how-it-works.html
>
> ... The main role of the PMC is not code and not coding ...
>
> Your committers are the people who do the work and the committers select new
> committers by merit.
>
> >
> > On 16/06/2014 19:19, Jason Pyeron wrote:
> > >> -----Original Message-----
> > >> From: Alain Forget
> > >> Sent: Monday, June 16, 2014 14:01
> > >>
> > >> Hm, this is an excellent point, to which I can think of two
> > >> possible solutions:
> > >
> > > I would ask, what would Apache do?
> > >
> > >>
> > >> A) We somehow come to a consensus as to precisely what
> > >> "tipping point" the community should become involved in any
> > >> informal discussions any member of the CipherShed community
> > >> is having with other parties. This tipping point could be:
> > >> Ai) Immediately; we tell the other party to post on our
> > >> mailing list to ensure everyone is always included, and that
> > >> there is an open and archived record of everything for all to see.
> > >
> > > This is the least practical.
> > >
> > >> Aii) Only once the CipherShed member feels there is alignment
> > >> and/or an actual potential impact to the project (rather than
> > >> just talk). This is the fuzziest (most open to said member's
> > >> judgement), and thus could still be problematic in the future.
> > >
> > > This is the most practical to implement, may be not the best.
> > >
> > >> Aiii) Only once there is a firm proposal by the CipherShed
> > >> member and the other party (although the CipherShed member
> > >> doesn't necessarily need to endorse the proposal, but at
> > >> least share it with the community to solicit responses).
> > >
> > > Can you define firm? I don't see this as very different from Aii.
> > >
> > >>
> > >> B) We appoint 1-3 people as points of contact for these
> > >> matters, as a spokeperson, public relations, or whatever
> > >> title as the point of contact. Any other community member who
> > >
> > > Again, look to apache, http://www.apache.org/dev/pmc.html &
> > > http://www.apache.org/foundation/how-it-works.html. You
> > > elect a PMC Chair, they govern they project, the chair is
> > elected from the
> > > project's members.
> > >
> > >> is contacted by outside parties should route said party to
> > >> these PR people. If there are more than one PR person, they
> > >> should *all* be involved in any discussions with outside
> > >
> > > "all" - That may not be practical either.
> > >
> > >> parties. These people should have a deep understanding of the
> > >> project and community goals (and keep in close tune with them
> > >> as it evolves), be able to articulate them, and regardless of
> > >> their own personal viewpoint, they should be able to
> > >> anticipate the community's response to particular proposals
> > >> by outside parties when interacting with them, so that the
> > >> community needn't be consulted on every little thing, which
> > >> has the added benefit of allowing devs and others to focus on
> > >> furthering CipherShed without these discussion distractions,
> > >> until they become very relevant and may bear some fruit.
> > >
> > > Good point.
> > >
> > >> Obviously, the community must trust these people to represent
> > >> the community accurately and as unbiased as possible, and to
> > >> give outside parties a good impression of our community/project.
> > >
> > > See above comment about election.
>
>
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> - -
> - Jason Pyeron PD Inc. http://www.pdinc.us -
> - Principal Consultant 10 West 24th Street #100 -
> - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
> - -
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> This message is copyright PD Inc, subject to license 20080407P00.
>
>
>
>
>
--
Niklas
At the time of writing, no warrants have ever been served to me, Niklas
Lemcke, nor am I under any personal legal compulsion concerning the
CipherShed project. I do not know of any searches or seizures of my
assets.
Other related posts:
