Closed Bug 941671 Opened 11 years ago Closed 11 years ago

Rename "mozilla-corporation-confidential" to "mozilla-employee-confidential" and update membership accordingly

Categories

(bugzilla.mozilla.org :: Administration, task)

Production
task
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: mhoye, Assigned: glob)

Details

Attachments

(1 file)

Mozilla Foundation employees logged in with Persona aren't able to access confidential bugs, despite it being relevant to their interests. I'm specifically thinking of https://bugzilla.mozilla.org/show_bug.cgi?id=931148 ... but there are others. Foundation employees should be on equal footing to MoCo staff here.
this isn't related to persona authentication. accounts using a @mozilla.com email address are automatically members of the "Confidential Mozilla Corporation Bug" group. @mozillafoundation.org accounts have a different group, "Confidential Mozilla Foundation Bug" (which moco employees aren't members of). this is a policy decision, not a technical one. i'll ask around to try to determine why the split exists, and if it's still required.
Component: Extensions: Persona → Administration
Summary: Foundation employees are unable to access private/confidential bugs. → Foundation employees are unable to access Corporation private/confidential bugs.
i've started a discussion on the mozilla.governance list to see if there are any objections to this request. note: we should also give corporate employees visibility of foundation bugs.
I think a thread in .governance is probably mot sufficient for collecting the feedback needed for this policy change. Can you reach out directly to the owners of components that use these groups most?
there's an off-list and off-bug discussion surrounding this issue. a serious roadblock surrounds issues which are NDA restricted to mozilla corporate employees but not to mozilla foundation employees.
But the Mozilla Foundation owns the Mozilla Corporation outright. And as far as I know there used to be a flag in Bugzilla that does exactly this, which was deprecated and then removed. I stand by my claim that we have a need here, but I'd like to understand the history and rationale to our current situation. So - rolling a 14 on this D20 and using my amulet of +2 needinfo - I summon a Gerv.
Flags: needinfo?(gerv)
OK, so following a series of discussions, I'd like to change this bug to a request for an "all-employees" security group, with the description indicating that it is explicitly not for NDA-related material. That should give us a security group that addresses the requirement without a lot of chance of misuse.
Assignee: nobody → glob
Flags: needinfo?(gerv)
Summary: Foundation employees are unable to access Corporation private/confidential bugs. → create a "mozilla-all-confidential" group
mhoye: so the issue is that moco-confidential includes NDAed stuff, and mofo people aren't included in the NDA? "mozilla-all-confidential" is IMO not a good name, because all of Mozilla is everyone in the community. "employee-confidential" would be better, as long as it didn't have HR issues if contractors were included. Otherwise, "staff-confidential" might be OK. Gerv
(In reply to Gervase Markham [:gerv] from comment #7) > mhoye: so the issue is that moco-confidential includes NDAed stuff, and mofo > people aren't included in the NDA? Almost. It is that "moco-confidential" is being used to cover both NDA'ed stuff and non-NDA'ed stuff that we'd like to remain confidential, and consequently non-NDA'ed issues that should be visible to MoFos are not. I support your staff- or employee-confidential proposals over mozilla-all-confidential.
i had a quick chat with :liz about this yesterday. we have many NDAs which are applicable to different groups of people, so having a single "nda" group in bugzilla wouldn't really work. due to the number of NDAs creating a group for each one isn't practical. i'm waiting to hear if NDAs applicable to moco staff are also applicable to foundation staff. if this is the case then that simplifies things. i'm also curious how NDAs work with regards to the different mozilla corporations (eg. i'm employed by an australian based company, not directly by the US mozilla corporation).
(In reply to Byron Jones ‹:glob› from comment #9) > we have many NDAs which are applicable to different groups of people, so > having a single "nda" group in bugzilla wouldn't really work. due to the > number of NDAs creating a group for each one isn't practical. And keeping the relevant bugs in the relevant groups would be a massive job. > i'm waiting to hear if NDAs applicable to moco staff are also applicable to > foundation staff. if this is the case then that simplifies things. It would indeed. We can just keep the existing group and add MoFo. I was assuming that the reason we were considering all these other options is that someone had determined that this wasn't the case. But perhaps I was wrong. Gerv
I may have expressed myself poorly here - this group is explicitly not for anything having to do with any NDA or partner agreement. Only for things that should remain confidential to Mozilla employees, a set that should include MoFos.
Hi all, I spoke with Denelle about this. She doesn't see any reason for there not to be a group for all employees of all Mozilla companies. The NDA issue is separate. Most NDAs only allow access to employees who need to know the confidential info, so if information covered by an NDA is going to be included in a bug, access to that bug should be restricted to the individual employees who need to see it to fulfill the purposes of the NDA. Hope that helps.
(In reply to Liz Compton [:liz] from comment #12) > > Hope that helps. That helps a lot. Thanks, Liz. - mhoye
What Liz says suggests that mozilla-corp-confidential is not being used for NDA'ed stuff anyway. So is there a problem with repurposing that group to be employee-confidential? That would mean MoFos would immediately gain access to any troublesomely inaccessible bugs, without lots having to be re-grouped. Gerv
I don't think "moco-confidential" and "mozilla-corp-confidential" should both exist but serve very different purposes. They look pretty much the same. Can we rename a group without screwing up membership? If so, renaming and reusing mozilla-corp-confidential to something less confusable seems like the right approach.
(In reply to Mike Hoye [:mhoye] from comment #15) > I don't think "moco-confidential" and "mozilla-corp-confidential" should > both exist but serve very different purposes. They look pretty much the > same. I think there's some confusion here, possibly caused by me. There is no group "moco-confidential". I wrote that because I was unsure of the true group name. The true group name is "mozilla-corporation-confidential". > Can we rename a group without screwing up membership? If so, renaming and > reusing mozilla-corp-confidential to something less confusable seems like > the right approach. Yes - it is but the work of a moment to rename mozilla-corporation-confidential to employee-confidential, and to change the inheritance memberships to include MoFos. No membership screwups. There may be impact on some stored queries, though - we'd need input from glob and dkl to quantify that. Gerv
Summary: create a "mozilla-all-confidential" group → create an "employee-confidential" group
OK, in that light I think your plan will solve the problem.
(In reply to Gervase Markham [:gerv] from comment #16) > Yes - it is but the work of a moment to rename > mozilla-corporation-confidential to employee-confidential, and to change the > inheritance memberships to include MoFos. No membership screwups. There may > be impact on some stored queries, though - we'd need input from glob and dkl > to quantify that. mozilla-corporation-confidential is a very heavily used group, and there's a few places to touch in code. nothing to scary there however. i'm not concerned about stored queries, however i _am_ concerned with breaking systems which create bugs via an API, so we'll have to provide reasonable notice prior to renaming that group. let's put this on hold until the new year; i'll blog about it once i'm back with an eye to renaming the group in the last week of january. > Summary: create a "mozilla-all-confidential" group → create an "employee-confidential" group i don't agree that employee-confidential is an appropriate name; mozilla-corporation-confidential members are everyone with, or eligible for, an @mozilla.com address. contractors and interns are included in that group. we could resurrect the "mozilla-confidential" name.
(In reply to Byron Jones ‹:glob› from comment #18) > let's put this on hold until the new year; i'll blog about it once i'm back > with an eye to renaming the group in the last week of january. OK, sounds good. > i don't agree that employee-confidential is an appropriate name; > mozilla-corporation-confidential members are everyone with, or eligible for, > an @mozilla.com address. contractors and interns are included in that group. What is the usual collective noun for "permanent employees, contractors and interns"? Unless one is talking to the IRS or HR, in common parlance "employee" is reasonable IMO. But I'm open to other suggestions. > we could resurrect the "mozilla-confidential" name. It would not be a case of resurrecting, as a group with this name already exists. So that one would have to be renamed to move it out of the way. I think that might be confusing. Also, the point of this group is that it is for people with some form of contractual employment relationship with Mozilla; "mozilla-confidential" doesn't capture that. Gerv
(In reply to Gervase Markham [:gerv] from comment #19) > What is the usual collective noun for "permanent employees, contractors and > interns"? Unless one is talking to the IRS or HR, in common parlance > "employee" is reasonable IMO. But I'm open to other suggestions. solid points grev; mozilla-employee-confidential it is :)
Summary: create an "employee-confidential" group → create an "mozilla-employee-confidential" group
glob: per comment 18, seems like the action here is for you to blog about the change. Is that right? Gerv
Summary: create an "mozilla-employee-confidential" group → Rename "mozilla-corporation-confidential" to "mozilla-employee-confidential" and update membership accordingly
Attached patch 941671_1.patchSplinter Review
Attachment #8362342 - Flags: review?(dkl)
Comment on attachment 8362342 [details] [diff] [review] 941671_1.patch Review of attachment 8362342 [details] [diff] [review]: ----------------------------------------------------------------- r=dkl
Attachment #8362342 - Flags: review?(dkl) → review+
err, ignore comment 25 :) Committing to: bzr+ssh://bjones%40mozilla.com@bzr.mozilla.org/bmo/4.2/ modified Bugzilla/Bug.pm modified extensions/BMO/Extension.pm modified extensions/BMO/lib/Data.pm modified extensions/BMO/lib/Reports/ProductSecurity.pm modified extensions/BMO/template/en/default/bug/create/create-dev-engagement-event.html.tmpl modified extensions/BMO/template/en/default/bug/create/create-legal.html.tmpl modified extensions/BMO/template/en/default/bug/create/create-presentation.html.tmpl modified extensions/BMO/template/en/default/bug/create/create-privacy-data.html.tmpl modified extensions/BMO/template/en/default/bug/create/create-recoverykey.html.tmpl modified extensions/BMO/template/en/default/hook/bug/create/create-form.html.tmpl modified extensions/MozProjectReview/Extension.pm modified extensions/MozProjectReview/web/js/moz_project_review.js Committed revision 9241.
the following changes have been made: - mozilla-corporation-confidential renamed to mozilla-employee-confidential - description changed to "Confidential Mozilla Employee Bug" - mozilla-foundation members are now members of this group - mozilla-corporation-confidential-visible renamed to mozilla-employee-confidential-visible - description changed to "Members of this group will be able to use the mozilla-employee-confidential group when filing bugs"
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: