Proposed "Policy" Activities Module
Mitchell Baker
The proposed module and initial sub-modules below. Thoughts very
welcome, publicly or privately -- these are things that many of us don't
discuss day to day but which underlie much of our work.
Mozilla Policy Module
owner: Mitchell Baker
peers:
newsgroup: mozilla.governance
governing policy document: n/a
scope: project-wide (applies to all Mozilla projects, unless specific
policies state a narrower scope for that policy)
responsibilities: Determine when a policy is appropriate / necessary,
draft policy and lead review and discussion, maintain policies, answer
interpretation and usage questions, identify sub-modules, owners and
particular peers for particular policies
The proposal for the initial sub-modules is below. Thoughts on other
policies that should be included welcome. Same with thoughts on peers.
Sub-Module: Commit Access Policy
owner: Mitchell Baker
peers:
newsgroup: mozilla.governance
governing policy document: ("Mozilla CA Certificate Policy"):
http://www.mozilla.org/hacking/committer/
scope: project-wide
Sub-Module: Security Policy
owner: Frank Hecker
peers:
newsgroup: mozilla.governance
governing policy document: ("Handling Mozilla Security Bugs"):
http://www.mozilla.org/projects/security/security-bugs-policy.html
scope: project-wide (applies to all Mozilla projects)
Sub-Module: Mozilla CA Certificate Policy
owner: Frank Hecker
peers:
newsgroup: mozilla.governance
governing policy document: ("Mozilla CA Certificate Policy"):
http://www.mozilla.org/projects/security/certs/policy/
scope: project-wide (applies to all Mozilla projects that includes
root certificates)
Sub-Module: Code Review Policy
owner: Mitchell Baker
peers: Brendan Eich
newsgroup: mozilla.governance
governing policy document: http://www.mozilla.org/hacking/reviewers.html
scope: project-wide
Sub-Module: Performance Regression Policy
owner: Mitchell Baker
peers:
newsgroup: mozilla.governance
governing policy document: http://www.mozilla.org/hacking/reviewers.html
scope: project-wide
Mitchell
Mike Connor
On Jan 7, 2009, at 10:57 AM, Mitchell Baker wrote:
>
> The proposed module and initial sub-modules below. Thoughts very
> welcome, publicly or privately -- these are things that many of us
> don't discuss day to day but which underlie much of our work.
>
> Sub-Module: Commit Access Policy
> owner: Mitchell Baker
> peers:
> newsgroup: mozilla.governance
> governing policy document: ("Mozilla CA Certificate Policy"):
> http://www.mozilla.org/hacking/committer/
If we were to adopt a more separated policy (i.e. more like how we've
handled SVN, where everything is access-controlled, based on the
project's needs) would this still exist? I think so, since we'd have
an overall policy around licensing and legal reqs and probably how to
get space for new projects/repos, and some language around each
project controlling their own access.
I recognize that this is going down a controversial path, when January
settles more I'll post separately as promised a while back to get the
discussion rolling there.
> Sub-Module: Code Review Policy
> owner: Mitchell Baker
> peers: Brendan Eich
> newsgroup: mozilla.governance
> governing policy document: http://www.mozilla.org/hacking/reviewers.html
> scope: project-wide
scope is likely wrong here, since I think this applies to mozilla-
central and perhaps comm-central, loosely. It doesn't seem to apply
to bugzilla or other webtools, or any other repo, explicitly. I'm due
to rewrite this based on changes to SR that are working through public
consultation, and I could take a stab at the idea of code review being
a project wide policy, with variations on number and scope and type
(SR, UI, etc) of reviews covered on a module by module basis.
-- Mike
Eddy Nigg
>
> The proposed module and initial sub-modules below. Thoughts very
> welcome, publicly or privately -- these are things that many of us don't
> discuss day to day but which underlie much of our work.
>
I thought that the Mozilla Policy Module should be policies which affect
third parties mostly. Such as the CA policy, maybe trademarks and
privacy policy and such stuff. Code review looks to me like an internal
policy - not sure if this should be here.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: star...@startcom.org
Blog: https://blog.startcom.org
Mike Connor
On Jan 7, 2009, at 1:59 PM, Eddy Nigg wrote:
> On 01/07/2009 05:57 PM, Mitchell Baker:
>>
>> The proposed module and initial sub-modules below. Thoughts very
>> welcome, publicly or privately -- these are things that many of us
>> don't
>> discuss day to day but which underlie much of our work.
>>
>
> I thought that the Mozilla Policy Module should be policies which
> affect third parties mostly. Such as the CA policy, maybe trademarks
> and privacy policy and such stuff. Code review looks to me like an
> internal policy - not sure if this should be here.
Why should it be only for policies that affect third parties? It's an
open project that has project-wide policies that are transparent and
public, and I don't understand the distinction you're trying to draw
here.
-- Mike
Eddy Nigg
Well, that's what I "thought". Transparency is excellent btw!
Mitchell Baker
responsible for critical decisions about how we operate. So I would
include all the policies here.
Eddy -- I thought about including Policies as a sub-module of
governance, but decided the structure would get too complex and we don't
want sub-modules of sub-modules unless we absolutely have to go there.
But even there I'm not sure how helpful a distinction we could make
between "internal" and not internal. The Commit Access policy affects
third parties who want commit access for example.
In the interests of not getting too complex as we start, I'm still
leaning to putting the official policies in one place and seeing if
that works.
mitchell
Mitchell Baker
>
> On Jan 7, 2009, at 10:57 AM, Mitchell Baker wrote:
>
>>
>> The proposed module and initial sub-modules below. Thoughts very
>> welcome, publicly or privately -- these are things that many of us
>> don't discuss day to day but which underlie much of our work.
>>
>> Sub-Module: Commit Access Policy
>> owner: Mitchell Baker
>> peers:
>> newsgroup: mozilla.governance
>> governing policy document: ("Mozilla CA Certificate Policy"):
>> http://www.mozilla.org/hacking/committer/
>
> If we were to adopt a more separated policy (i.e. more like how we've
> handled SVN, where everything is access-controlled, based on the
> project's needs) would this still exist? I think so, since we'd have an
> overall policy around licensing and legal reqs and probably how to get
> space for new projects/repos, and some language around each project
> controlling their own access.
>
> I recognize that this is going down a controversial path, when January
> settles more I'll post separately as promised a while back to get the
> discussion rolling there.
There are a couple of related questions involved here:
-- Can a repository have a different policy on commit access
-- Who decides if a repository has a different policy on commit
access; is there some project wide action needed to OK this?
-- In any case, the question of potential "qrandfathering" of
existing practices of existing projects
>
>> Sub-Module: Code Review Policy
>> owner: Mitchell Baker
>> peers: Brendan Eich
>> newsgroup: mozilla.governance
>> governing policy document: http://www.mozilla.org/hacking/reviewers.html
>> scope: project-wide
>
> scope is likely wrong here, since I think this applies to
> mozilla-central and perhaps comm-central, loosely. It doesn't seem to
> apply to bugzilla or other webtools, or any other repo, explicitly. I'm
> due to rewrite this based on changes to SR that are working through
> public consultation, and I could take a stab at the idea of code review
> being a project wide policy, with variations on number and scope and
> type (SR, UI, etc) of reviews covered on a module by module basis.
>
As a first step, let's see if you can get code review sorted out for
mozilla-central and comm-central; that alone would be a good step. If
the larger issues fit into that or grow from thinking about it great.
On the meta level, it might be that the code review policy itself
applies project wide, and the policy sets out different levels for
different projects. In other words, a project doesn't get to decide for
itself that it will skip code review, some other Mozilla mechanism must
be involved. (I'm not saying this is what we'll end up with, we should
consider what we went here.)
mitchell
> -- Mike
Mitchell Baker
>
> On Jan 7, 2009, at 10:57 AM, Mitchell Baker wrote:
>
>>
>> The proposed module and initial sub-modules below. Thoughts very
>> welcome, publicly or privately -- these are things that many of us
>> don't discuss day to day but which underlie much of our work.
>>
>> Sub-Module: Commit Access Policy
>> owner: Mitchell Baker
>> peers:
>> newsgroup: mozilla.governance
>> governing policy document: ("Mozilla CA Certificate Policy"):
>> http://www.mozilla.org/hacking/committer/
>
> If we were to adopt a more separated policy (i.e. more like how we've
> handled SVN, where everything is access-controlled, based on the
> project's needs) would this still exist? I think so, since we'd have an
> overall policy around licensing and legal reqs and probably how to get
> space for new projects/repos, and some language around each project
> controlling their own access.
>
> I recognize that this is going down a controversial path, when January
> settles more I'll post separately as promised a while back to get the
> discussion rolling there.
There are a couple of related questions involved here:
-- Can a repository have a different policy on commit access
-- Who decides if a repository has a different policy on commit
access; is there some project wide action needed to OK this?
-- In any case, the question of potential "qrandfathering" of
existing practices of existing projects
>
>> Sub-Module: Code Review Policy
>> owner: Mitchell Baker
>> peers: Brendan Eich
>> newsgroup: mozilla.governance
>> governing policy document: http://www.mozilla.org/hacking/reviewers.html
>> scope: project-wide
>
> scope is likely wrong here, since I think this applies to
> mozilla-central and perhaps comm-central, loosely. It doesn't seem to
> apply to bugzilla or other webtools, or any other repo, explicitly. I'm
> due to rewrite this based on changes to SR that are working through
> public consultation, and I could take a stab at the idea of code review
> being a project wide policy, with variations on number and scope and
> type (SR, UI, etc) of reviews covered on a module by module basis.
>
Reed Loden
Mitchell Baker <mitc...@mozilla.com> wrote:
> The proposed module and initial sub-modules below. Thoughts very
> welcome, publicly or privately -- these are things that many of us
> don't discuss day to day but which underlie much of our work.
I'd like to self-nominate myself for module peer of the following
modules and sub-modules:
* Mozilla Policy module -- interested in helping to produce new policies
* Commit Access Policy sub-module -- deal with this almost daily as
an active Despot, so it means a lot to me
* Security Policy sub-module -- as a new member of the security group,
I'm interested in changes related to the security bug policy
~reed
--
Reed Loden - <re...@reedloden.com>
Samuel Sidler
> Sub-Module: Security Policy
> owner: Frank Hecker
> peers:
> newsgroup: mozilla.governance
> governing policy document: ("Handling Mozilla Security Bugs"):http://www.mozilla.org/projects/security/security-bugs-policy.html
> scope: project-wide (applies to all Mozilla projects)
How does this play into / relate to the "Mozilla security module"
mentioned on that policy doc?
That doc also mentions that the security-group discusses policy on a
mailing list, which seems to imply that the group, itself, helps
decide it. How does that relate to the owner/peers of this sub-module?
Related: Are all security-group members also "members" of this sub-
module?
-Sam
Samuel Sidler
> * Security Policy sub-module -- as a new member of the security group,
> I'm interested in changes related to the security bug policy
I'd argue that those changes should be vetted through the security
group anyway, otherwise the entire security group should be a peer of
this sub-module. ;)
-Sam
Reed Loden
Sounds good to me. One of the reasons I specifically wanted to join the
security group was to help in future policy related to how we handle
security issues/bugs.
Mitchell Baker
changes to the policy. The peer, in our system does as well. I expect
that in these modules peers will work closely with other peers and the
module owner.
There are plenty of other people who are critical to making a good
policy. People whose input is required to figure out and maintain a
good policy and people whose actions are required to implement and
maintain a policy. I don't think all of these people should be owners
or peers.
"Members" is a concept we haven't explicitly defined across modules, so
I'm not sure. Members in the locked partitions (NSS< NSPR) are those
who can commit code. That isn't analogous here. "Members" could mean
people whose input is important. But then it means different things.
The security group absolutely helps decide policy. Otherwise we would
be writing policy in a vacuum. So i would say that the security group
members are people who input and involvement is required for policy
development and implementation. This is the group that will let us
(specifically, me as Policy module owner and ultimately Brendan as
Module Ownership module) if the policy owner has lost the support of the
group.
As to mozilla security module, I'll check and see if we actually have
one. I don't want to change the workings of the security group and
anyone else working on security.
Mitchell
Mitchell Baker
I think Sam's right, that changes in the security policy should be
vetted by the security group. This is probably true of all policies --
there is some group of people whose input is critical. The group will
vary with each policy, but in every case we need to make sure that
changes to policy are grounded in real need and improve the setting.
Mitchell
Mitchell Baker
Reed wrote:
One of the reasons I specifically wanted to join the
> security group was to help in future policy related to how we handle
> security issues/bugs.
>
> ~reed
>
I suggest we leave the peers as the people who are authorized to
actually change our policies. That leaves us without a clear designatio
n for the people who are particularly interested or whose input is
particularly critical. That's a good issue to solve, but I'd rather not
use peers for this purpose. Certainly the module owner and peers should
have a good sense of this.
We might consider adding a line on the Activities Modules template
like:"related groups." I bit bit worried this will get complex and
confusing but maybe there's a good way to do this.
Gen Kanai
On Jan 8, 2009, at 12:57 AM, Mitchell Baker wrote:
>
> The proposed module and initial sub-modules below. Thoughts very
> welcome, publicly or privately -- these are things that many of us
> don't discuss day to day but which underlie much of our work.
Mitchell,
I'm glad these areas are getting the attention that they deserve.
I'm wondering if we can find peers for the policy modules that do not
have them in this first draft? I realize that most of this is
reflecting the work that is already done by the owners to date, but if
there are no peers, it would benefit us to take this opportunity to
consider peers at this time vs. some later date.
Gen
Benjamin Smedberg
In general I don't think we need "peers" for many of these policy modules.
We use peers to distribute review workload among more than a single person
and avoid backlog: but in most cases where you're changing a policy, you
*want* to have a single person making decisions.
In general I think module owners are responsible for nominating/selecting
peers for their modules.
--BDS
Reed Loden
Mitchell Baker <mitc...@mozilla.com> wrote:
> I suggest we leave the peers as the people who are authorized to
> actually change our policies. That leaves us without a clear
> designatio n for the people who are particularly interested or whose
> input is particularly critical. That's a good issue to solve, but
> I'd rather not use peers for this purpose. Certainly the module
> owner and peers should have a good sense of this.
Sure, that sounds great. I just wanted to say that I was definitely
interested in helping out with these new modules in whatever way I can,
whether it be officially or unofficially.
Mitchell Baker
people with interest and growing experience in this area.
Mitchell Baker
I share what I think is Gen's core interest -- identifying people
interested in policy and developing more people with experience in
developing, writing and maintain appropriate policies.
It's hard to find peers until we do some of this. I'd like to stick
with the general approach of delegating authority to people who are
doing the job, or doing parts of the job and where it seems obvious to
people that the delegation makes sense. I'd like to get to that point
with some of the policies, but I'm not sure we're there yet. I also
hope not to create a lot of extra policies as a result of being explicit
here, we can really only support policies that are important enough for
people to internalize and enforce them.
I think the way to do this is to see who emerges and does good work as
policy issues arise. Other thoughts and approaches more than welcome.
Mitchell
Frank Hecker
Yes. Just to be clear on my position vis-a-vis all this: Policies are
created through a public process of seeking consensus among the various
stakeholders. If I'm a module owner for a policy, my primary job is to
initiate, participate in, and help guide that public discussion, to try
to clarify the various positions that surface in discussion and find
appropriate policy language to express them, to seek a consensus around
particular parts of the policy wherever possible, and where no consensus
exists to propose a policy approach that can at least be justified to
everyone in a reasonable way, even if some don't agree with it.
So, to sum up, if I am the official policy owner for the security policy
then there's no way I'd change it without the involvement and backing of
the security group.
Frank
--
Frank Hecker
hec...@mozillafoundation.org
Mitchell Baker
-- some level of leadership is involved. Sometimes there are decisions
which are controversial and yet which need to be made, and that's part
of the role. I think this is implicit in Frank's comments, but I feel
compelled to make it explicit.
Part of the reason that module ownership is important is that the owner
has the respect, experience, background, trust of the necessary people
to make these decisions. A constant dose of these is can be a sign of a
problem. Knowing when this is the case and when reaching a better
consensus as Frank describes is required is part of the role.
Mitchell Baker
> On 01/07/2009 05:57 PM, Mitchell Baker:
>>
>> The proposed module and initial sub-modules below. Thoughts very
>> welcome, publicly or privately -- these are things that many of us don't
>> discuss day to day but which underlie much of our work.
>>
>
> I thought that the Mozilla Policy Module should be policies which affect
> third parties mostly. Such as the CA policy, maybe trademarks and
> privacy policy and such stuff. Code review looks to me like an internal
> policy - not sure if this should be here.
>
>
I'm coming back to this thread, at long last.
This is an interesting idea. I think a bunch of us have had the
opposite assumption without ever particularly articulating it -- that
there are core policies which concern how the project operates -- how we
delegate authority, how we build and improve our key assets -- code,
community, communication. So I'll bet there are a number of people who
would view what you have called "internal" policies as fundamental.
For now I think I'm going to continue to put anything policy like in one
bucket. As we get further with activities modules and if we find this
ends up confusing we can split them out. But right now these policies
about how we govern ourselves are important to review and update.
Putting themsomewhere else or under a different title will only shift
attention to whatever the new title is.
If anyone feels otherwise, please speak up.
Mitchell
Eddy Nigg
> Eddy Nigg wrote:
>> On 01/07/2009 05:57 PM, Mitchell Baker:
>>>
>>> The proposed module and initial sub-modules below. Thoughts very
>>> welcome, publicly or privately -- these are things that many of us
>>> don't
>>> discuss day to day but which underlie much of our work.
>>>
>>
>> I thought that the Mozilla Policy Module should be policies which
>> affect third parties mostly. Such as the CA policy, maybe trademarks
>> and privacy policy and such stuff. Code review looks to me like an
>> internal policy - not sure if this should be here.
>>
>>
> Eddy
>
> I'm coming back to this thread, at long last.
> This is an interesting idea. I think a bunch of us have had the
> opposite assumption without ever particularly articulating it -- that
> there are core policies which concern how the project operates -- how
> we delegate authority, how we build and improve our key assets --
> code, community, communication. So I'll bet there are a number of
> people who would view what you have called "internal" policies as
> fundamental.
Well, that's certainly correct too. I was looking at it more from a
third-party point of view.
>
> For now I think I'm going to continue to put anything policy like in
> one bucket. As we get further with activities modules and if we find
> this ends up confusing we can split them out. But right now these
> policies about how we govern ourselves are important to review and
> update. Putting themsomewhere else or under a different title will
> only shift attention to whatever the new title is.
>
I think it would be a good idea to split internal (but fundamental)
policies and those that affect (or may affect or may have an impact on)
third parties.
Gervase Markham
> I think it would be a good idea to split internal (but fundamental)
> policies and those that affect (or may affect or may have an impact on)
> third parties.
I'm not sure such a split is possible. As a public project, almost
everything we do has some impact on someone. For example, the code
review policy affects third parties who want to get their patches into
our tree.
Why not go with what Mitchell is proposing for now? If you can show in
the future how having them in the same bucket is detrimental (and how to
define the line which separates the buckets), we can reconsider.
Gerv
Eddy Nigg
> On 02/06/09 02:43, Eddy Nigg wrote:
>> I think it would be a good idea to split internal (but fundamental)
>> policies and those that affect (or may affect or may have an impact on)
>> third parties.
>
> I'm not sure such a split is possible. As a public project, almost
> everything we do has some impact on someone. For example, the code
> review policy affects third parties who want to get their patches into
> our tree.
>
> Why not go with what Mitchell is proposing for now?
Certainly, I hope my comment doesn't hold up anything.
> If you can show in the future how having them in the same bucket is
> detrimental (and how to define the line which separates the buckets),
> we can reconsider.
I simply feel that trademarks, distribution and perhaps CA policies (and
maybe others) might have some legal consequences affecting third parties
(about which third parties must know) whereas some code related,
management orientated policies perhaps have a different target audience
and none of the strings attached from above. I think that's all I tried
to say here.
Mitchell Baker
>
> On Jan 7, 2009, at 10:57 AM, Mitchell Baker wrote:
>
>>
>> The proposed module and initial sub-modules below. Thoughts very
>> welcome, publicly or privately -- these are things that many of us
>> don't discuss day to day but which underlie much of our work.
>>
>> Sub-Module: Commit Access Policy
>> owner: Mitchell Baker
>> peers:
>> newsgroup: mozilla.governance
>> governing policy document: ("Mozilla CA Certificate Policy"):
>> http://www.mozilla.org/hacking/committer/
>
> If we were to adopt a more separated policy (i.e. more like how we've
> handled SVN, where everything is access-controlled, based on the
> project's needs) would this still exist? I think so, since we'd have an
> overall policy around licensing and legal reqs and probably how to get
> space for new projects/repos, and some language around each project
> controlling their own access.
>
> I recognize that this is going down a controversial path, when January
> settles more I'll post separately as promised a while back to get the
> discussion rolling there.
I'm pretty sure that Commit Acces is a project wide topic. We may have
different rules for different repos, that seems likely. But still
someone should take the overview -- are there basic things as you
suggest? Or for example, requiring a clear public statement of what
commit access requirements are, and some place to raise issues.
>
>> Sub-Module: Code Review Policy
>> owner: Mitchell Baker
>> peers: Brendan Eich
>> newsgroup: mozilla.governance
>> governing policy document: http://www.mozilla.org/hacking/reviewers.html
>> scope: project-wide
>
> scope is likely wrong here, since I think this applies to
> mozilla-central and perhaps comm-central, loosely. It doesn't seem to
> apply to bugzilla or other webtools, or any other repo, explicitly. I'm
> due to rewrite this based on changes to SR that are working through
> public consultation, and I could take a stab at the idea of code review
> being a project wide policy, with variations on number and scope and
> type (SR, UI, etc) of reviews covered on a module by module basis.
>
> -- Mike
Pretty much the same answer as above. Code Review may vary by project,
or for different parts of a project. But someone should have the
project view of how we treat our code, what if anything should be
consistent, is there a baseline, etc.
Mitchell
Mitchell Baker
change in plans is to create them as part of the governance module. I
didn't hear any concerns about creating these roles before so i don't
expect much now. but let me know if something concerns you.
anyone who is interested in working on policy and governance issues; let
me know. (Reed, you're on the list). There's some work to be done and
building a group of interested and experienced people is as important as
in other modules.
mitchell
Mitchell Baker wrote:
>
> The proposed module and initial sub-modules below. Thoughts very
> welcome, publicly or privately -- these are things that many of us don't
> discuss day to day but which underlie much of our work.
>
>
> Mozilla Policy Module
> owner: Mitchell Baker
> peers:
> newsgroup: mozilla.governance
> governing policy document: n/a
> scope: project-wide (applies to all Mozilla projects, unless specific
> policies state a narrower scope for that policy)
> responsibilities: Determine when a policy is appropriate / necessary,
> draft policy and lead review and discussion, maintain policies, answer
> interpretation and usage questions, identify sub-modules, owners and
> particular peers for particular policies
>
> The proposal for the initial sub-modules is below. Thoughts on other
> policies that should be included welcome. Same with thoughts on peers.
>
>
> Sub-Module: Commit Access Policy
> owner: Mitchell Baker
> peers:
> newsgroup: mozilla.governance
> governing policy document: ("Mozilla CA Certificate Policy"):
> http://www.mozilla.org/hacking/committer/
> scope: project-wide
>
> Sub-Module: Security Policy
> owner: Frank Hecker
> peers:
> newsgroup: mozilla.governance
> governing policy document: ("Handling Mozilla Security Bugs"):
> http://www.mozilla.org/projects/security/security-bugs-policy.html
> scope: project-wide (applies to all Mozilla projects)
>
> Sub-Module: Mozilla CA Certificate Policy
> owner: Frank Hecker
> peers:
> newsgroup: mozilla.governance
> governing policy document: ("Mozilla CA Certificate Policy"):
> http://www.mozilla.org/projects/security/certs/policy/
> scope: project-wide (applies to all Mozilla projects that includes
> root certificates)
>
> Sub-Module: Code Review Policy
> owner: Mitchell Baker
> peers: Brendan Eich
> newsgroup: mozilla.governance
> governing policy document: http://www.mozilla.org/hacking/reviewers.html
> scope: project-wide
>
> Sub-Module: Performance Regression Policy
> owner: Mitchell Baker
> peers:
> newsgroup: mozilla.governance
> governing policy document: http://www.mozilla.org/hacking/reviewers.html
> scope: project-wide
>
> Mitchell