[ciphershed] Re: Organization structure?
- From: "Alain Forget" <aforget@xxxxxxx>
- To: <ciphershed@xxxxxxxxxxxxx>
- Date: Mon, 23 Jun 2014 12:33:55 -0400
-----Original Message-----
From: ciphershed-bounce@xxxxxxxxxxxxx [mailto:ciphershed-bounce@xxxxxxxxxxxxx]
On Behalf Of Niklas Lemcke - ???
Sent: Monday, June 23, 2014 11:01
To: ciphershed@xxxxxxxxxxxxx
Subject: [ciphershed] Re: Organization structure?
On Mon, 23 Jun 2014 22:58:56 +0800
Niklas Lemcke - 林樂寬 <compul@xxxxxxxxxxxxxx> wrote:
> On Mon, 23 Jun 2014 10:54:44 -0400
> "Alain Forget" <aforget@xxxxxxx> wrote:
>
> >
> > On Mon, 23 Jun 2014 09:35:29 -0400
> > Stephen R Guglielmo <srguglielmo@xxxxxxxxx> wrote:
> >
> > > On Mon, Jun 23, 2014 at 7:57 AM, Bill Cox <waywardgeek@xxxxxxxxx> wrote:
> > > > I prefer for CipherShed to remain an unincorporated non-profit for
> > > > now, though when we do incorporate, it should not be in the US.
> > > > Someone with expertise in the local laws of whatever country hosts
> > > > CipherShed will have to be involved.
> > > >
> > > > I like what I have read so far about Adobe's PMC structure. Perhaps
> > > > we could start with a simplified version and grow from there?
> > > >
> > > > The PMC structure seems similar to many co-ops. Co-ops typically
> > > > elect board members each year. I think eventually, we may want a
> > > > structure like that, but right now, how many actual contributors do we
> > > > have? Isn't it something like 10-ish people? While that is large for
> > > > a board, it seems silly for 10 people to vote for 5 of us to be on a
> > > > board. We have only six "authors" listed on the web site, and that is
> > > > certainly not too many for an initial steering committee. There are
> > > > people missing from this page, who are contributing. Should we ask
> > > > that to have a vote, contributors need to allow us to list them on the
> > > > About page?
> > > >
> > > > I also continue to feel strongly that we need geeks who can verify and
> > > > protect the code base to be responsible for the code. I think we
> > > > should have a "security team" for this. This would be people willing
> > > > to sign that they have personally verified releases, and likely
> > > > includes most of us who write code to start. This team should not try
> > > > to do the job of the steering committee (or whatever we call it). It
> > > > should instead narrowly focus on security, but should have the final
> > > > say over code-related issues.
> > >
> > > I tend to agree with Bill. I think we should define a specific
> > > "security team" to manage security and related issues. I do think our
> > > project is too small right now to have a full-blown Project Management
> > > Committee right now, but maybe that is something we should start
> > > establishing now so when we do need it in the future, it'll be there.
> > >
> >
> > Not sure if I understood correctly. Security Team next to a PMC, or for
> > now just a Security Team, which later may be expanded to a PMC-ish
> > structure?
> >
> > Pls help
>
> I agree with you on the last paragraph, Alain.
>
> Also, I appreciate you to try and not top-post. But write above my
> signature next time ;)
>
However, I do think the QA / security core should have the last say
concerning code being merged or not.
When and how should we proceed to officially form those two groups? I
think it's a good idea to have them in place early, before there are
too many people that make things complicated.
--
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.
> Also, I appreciate you to try and not top-post. But write above my signature
> next time ;)
Geez, even when I bottom-post, you're *still* not happy! :-P More seriously
though, I'm not sure writing above your sig makes sense, because then how will
people know who wrote what? I'm deliberately writing below your sig so that
it's clearer what I'm saying, versus what you said. Of course, I'm relatively
new to this bottom-posting thing, so maybe I'm doin' it wrong. :-)
> However, I do think the QA / security core should have the last say
> concerning code being merged or not.
Hm, given that the PMC is supposed to be the direction and decision-making
entity, I do think they should have the final stamp of approval on all code
merges into the main branch. In most cases, I don't see why they wouldn't take
the QA team's recommendation, but I think an extra check-and-balance would be
good for accountability purposes. Furthermore, the PMC should to consider more
than just the code's own security integrity, such as branding, software
usability, UX concerns, software architecture, maintain good coding
practices/standards, and so on. However, the integrity of the code base is of
such paramount importance that I definitely agree we should have a team
specifically for such code verification, who would advise (and have a strong
voice on) the PMC on such issues.
> When and how should we proceed to officially form those two groups? I think
> it's a good idea to have them in place early, before there are too many
> people that make things complicated.
Agreed. When? ASAP, as far as I'm concerned. How? This is an open question I've
posed a number of times, since it's not clear to me how to seed them. However,
here's my first stab at it:
1) We first form the PMC as follows:
1a) Someone in our community (let's call her Alice) nominates a candidate
(let's call him Bob) to the PMC. A person cannot nominate themselves.
1b) The candidate Bob accepts the (Alice's) nomination to the PMC. Otherwise,
the nomination/candidacy dies.
1c) A second in the community (let's call her Cathy) seconds/supports the
nomination. If no second person supports the nomination, it dies. The original
nominator (Alice) or candidate (Bob) cannot support their own
nomination/candidacy.
1d) This is where it can go one of many ways. Either:
1di) The community then votes on whether or not this person should be on the
PMC (+1 = in favour, 0 = abstain (no vote), -1 = against). Anyone (including
nominees) may vote except for the candidate. If the final result is positive,
the person is appointed to the PMC. If the result is 0 or negative, the person
is not appointed and cannot be nominated again. Open question: Should these
votes be anonymous, to avoid possible political animosity forming within the
community? Anonymity is obviously counter to our stated mandate, so I am torn
on this point.
1dii) A third person (let's call him David) must also support the nomination,
at which point the candidate would be appointed to the PMC. Otherwise, the
candidacy dies.
1diii) No additional steps are required; the person is immediately appointed
after someone has supported the nomination.
2) Once the PMC is formed, then the PMC may appoint members to the Security/QA
Team as follows (and this procedure could be used for the length of the
project):
2a) A PMC member (let's call her Elaine) nominates (to the rest of the PMC) a
candidate (let's call him Francis) for the Security/QA Team. A person cannot
nominate themselves.
2b) A second PMC member (let's call her Gladys) seconds/supports the
nomination. If no second PMC member supports the nomination, it dies.
2c) The PMC then votes on whether or not this person should be offered a
position on the Security/QA Team (+1 = in favour, 0 = abstain (no vote), -1 =
against). Anyone (including nominees) may vote except for the candidate, if the
candidate happens to be on the PMC. If the final result is positive, the person
is invited to join the Security/QA Team. If the result is 0 or negative, then
there is no invitation. Same open question: Should these votes be anonymous, to
avoid possible political animosity forming within the PMC? In this case, I
don't think it should be anonymous, because the PMC should definitely be
accountable and adult enough to not take anyone's opposition to motions
personally/politically.
All the above for both procedures steps should have some time limit before
additional nominations/votes are no longer valid/counted. The Apache PMC page
(https://www.apache.org/dev/pmc.html) seems to consider 72 hours as sufficient
time, so that sounds reasonable to me. Furthermore, if a nomination fails, the
person cannot be nominated again (at least not in this initial forming stage,
but once the PMC is formed, they should decide some length of time before a
failed candidate can be nominated again).
Also, once the PMC is initially formed, they should then decide on how new PMC
members are chosen. Perhaps they'll want to continue with the same procedure,
or maybe they'll think it should be kept entirely internal to the PMC, rather
than brought to a full community vote. Up to them.
Keep in mind that I have no experience in forming these kinds of organisations,
so I can't speak for how fair/effective this process would be, but this is just
what I came up with, thinking about it over the past week or so.
Alain
Other related posts:
