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.