Re: company-confidential or mozillian-confidential?
On 13/04/2015 05:46, Benjamin Kerensa wrote: In the cases of things that truly need to be company-confidential then those could still be marked but unless a strong justification could be given for flagging company-confidential then bugs that would ordinarily be made company-confidential would be mozillian-confidential. Thoughts? Overall, I think we overuse company-confidential and I would prefer that more bugs became public. Can you give a few examples of the types of bugs where you believe company-confidential is wrong and yet they can't be public? ~ Gijs ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
Re: company-confidential or mozillian-confidential?
I'd love to see a formal audit. Like, have some team go through and figure out where are all these policies, who does what in private and why do they do it in private? I wonder if anyone in the organization has a complete view like this? I'm not opposed to things needing to be private, but it should be consistent, and it should be explained why it can't be. I think also if there were a group starting off with an audit, then that could also be the start of a group that helps try to "solve" for some things that we wish are public, but don't have a good plan around how to do that well. On Mon, Apr 13, 2015 at 8:24 AM, Gijs Kruitbosch wrote: > On 13/04/2015 05:46, Benjamin Kerensa wrote: > >> In the cases of things that truly need to be company-confidential then >> those could still be marked but unless a strong justification could be >> given for flagging company-confidential then >> >> bugs that would ordinarily be made company-confidential would be >> mozillian-confidential. >> >> Thoughts? >> > > Overall, I think we overuse company-confidential and I would prefer that > more bugs became public. > > Can you give a few examples of the types of bugs where you believe > company-confidential is wrong and yet they can't be public? > > ~ Gijs > > ___ > governance mailing list > governance@lists.mozilla.org > https://lists.mozilla.org/listinfo/governance > ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
Re: company-confidential or mozillian-confidential?
Not publicly no :) and that's why I suggest a nda-confidential or mozillians-confidential. I would like to see more public too but for the most part the ones I run into and have to be cc'ed on or ask about are operational stuff but not something that demands company-confidential over mozillians - confidential. On Apr 13, 2015 5:25 AM, "Gijs Kruitbosch" wrote: > > On 13/04/2015 05:46, Benjamin Kerensa wrote: >> >> In the cases of things that truly need to be company-confidential then >> those could still be marked but unless a strong justification could be >> given for flagging company-confidential then >> >> bugs that would ordinarily be made company-confidential would be >> mozillian-confidential. >> >> Thoughts? > > > Overall, I think we overuse company-confidential and I would prefer that more bugs became public. > > Can you give a few examples of the types of bugs where you believe company-confidential is wrong and yet they can't be public? > > ~ Gijs > ___ > governance mailing list > governance@lists.mozilla.org > https://lists.mozilla.org/listinfo/governance ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
Re: company-confidential or mozillian-confidential?
I don't understand the "not publicly" part. They're just bug IDs. Bugzilla will take care of security. I don't understand what you mean by "operational stuff" - you mean IT/ops ? I kind of presume you mean something else (as it seems to me that it's fair for some IT/ops bugs to be confidential as they'll involve office/server internals that shouldn't be public). ~ Gijs On 13/04/2015 18:30, Benjamin Kerensa wrote: Not publicly no :) and that's why I suggest a nda-confidential or mozillians-confidential. I would like to see more public too but for the most part the ones I run into and have to be cc'ed on or ask about are operational stuff but not something that demands company-confidential over mozillians - confidential. On Apr 13, 2015 5:25 AM, "Gijs Kruitbosch" wrote: On 13/04/2015 05:46, Benjamin Kerensa wrote: In the cases of things that truly need to be company-confidential then those could still be marked but unless a strong justification could be given for flagging company-confidential then bugs that would ordinarily be made company-confidential would be mozillian-confidential. Thoughts? Overall, I think we overuse company-confidential and I would prefer that more bugs became public. Can you give a few examples of the types of bugs where you believe company-confidential is wrong and yet they can't be public? ~ Gijs ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
Re: company-confidential or mozillian-confidential?
That would be pretty time consuming to do an across the board audit. I think the thing is Mozilla is a corporation at the end of the day and not everyone it hires cares about the manifesto or open source and so working in the open is not a priority and defaulting to corporate norms is something that just happens. I've seen this happen where a employee who just started working in the open leaves and is replaced by a new hire with a corporate background who defaults the work that was already being done in the open back to closed. Anyways to the point of bugs I think their needs to be some criteria for what should and should not be company-confidential. I think we need a new - confidential group added as a less restrictive level and with criteria and go from there. On Apr 13, 2015 10:17 AM, "Majken Connor" wrote: > > I'd love to see a formal audit. Like, have some team go through and figure > out where are all these policies, who does what in private and why do they > do it in private? I wonder if anyone in the organization has a complete > view like this? > > I'm not opposed to things needing to be private, but it should be > consistent, and it should be explained why it can't be. > > I think also if there were a group starting off with an audit, then that > could also be the start of a group that helps try to "solve" for some > things that we wish are public, but don't have a good plan around how to do > that well. > > On Mon, Apr 13, 2015 at 8:24 AM, Gijs Kruitbosch > wrote: > > > On 13/04/2015 05:46, Benjamin Kerensa wrote: > > > >> In the cases of things that truly need to be company-confidential then > >> those could still be marked but unless a strong justification could be > >> given for flagging company-confidential then > >> > >> bugs that would ordinarily be made company-confidential would be > >> mozillian-confidential. > >> > >> Thoughts? > >> > > > > Overall, I think we overuse company-confidential and I would prefer that > > more bugs became public. > > > > Can you give a few examples of the types of bugs where you believe > > company-confidential is wrong and yet they can't be public? > > > > ~ Gijs > > > > ___ > > governance mailing list > > governance@lists.mozilla.org > > https://lists.mozilla.org/listinfo/governance > > > ___ > governance mailing list > governance@lists.mozilla.org > https://lists.mozilla.org/listinfo/governance ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
Re: company-confidential or mozillian-confidential?
Operational: - Financial - Marketing - Events - Some roadmap/product bugs No IT/Ops makes sense much like sec bugs do. On Apr 13, 2015 10:34 AM, "Gijs Kruitbosch" wrote: > > I don't understand the "not publicly" part. They're just bug IDs. Bugzilla will take care of security. > > I don't understand what you mean by "operational stuff" - you mean IT/ops ? I kind of presume you mean something else (as it seems to me that it's fair for some IT/ops bugs to be confidential as they'll involve office/server internals that shouldn't be public). > > ~ Gijs > > > On 13/04/2015 18:30, Benjamin Kerensa wrote: >> >> Not publicly no :) and that's why I suggest a nda-confidential or >> mozillians-confidential. I would like to see more public too but for the >> most part the ones I run into and have to be cc'ed on or ask about are >> operational stuff but not something that demands company-confidential over >> mozillians - confidential. >> >> On Apr 13, 2015 5:25 AM, "Gijs Kruitbosch" wrote: >>> >>> >>> On 13/04/2015 05:46, Benjamin Kerensa wrote: In the cases of things that truly need to be company-confidential then those could still be marked but unless a strong justification could be given for flagging company-confidential then bugs that would ordinarily be made company-confidential would be mozillian-confidential. Thoughts? >>> >>> >>> >>> Overall, I think we overuse company-confidential and I would prefer that >> >> more bugs became public. >>> >>> >>> Can you give a few examples of the types of bugs where you believe >> >> company-confidential is wrong and yet they can't be public? >>> >>> >>> ~ Gijs >>> ___ >>> governance mailing list >>> governance@lists.mozilla.org >>> https://lists.mozilla.org/listinfo/governance > > ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
Proposed new submodules: WebRTC Signaling, WebRTC Media
The existing WebRTC module is now considerably larger and more complex
than when it was first conceived, and the people working on it are
becoming increasingly specialized. In particular, there is a clear
distinction between the code that deals primarily with the media
subsystem and the code that deals with signaling. Splitting this module
would reflect the actual split in expertise between media processing and
signaling.
Name: WebRTC
Description: WebRTC is responsible for realtime audio and video
communication, as well as related issues like low-level camera and
microphone access
Module Owner: Randell Jesup
Peers: Eric Rescorla, Ethan Hugg, Byron Campen, Adam Roach
Source Dir(s): N/A (see submodules)
Bugzilla Component(s): Core::WebRTC
URL: https://wiki.mozilla.org/Media/webrtc
Submodules of WebRTC
Name: WebRTC Media
Description: Submodule of WebRTC responsible for access to media input
devices (microphones, cameras, screen capture), as well as realtime
audiovisual codecs and packetization.
Owner: Randell Jesup
Peer(s): Ethan Hugg, Paul Kerr
Source Dir(s): /media/webrtc, /dom/media/webrtc
Bugzilla Component(s): Core::WebRTC (Audio/Video)
Name: WebRTC Signaling
Description: Submodule of WebRTC responsible for implementation of
PeerConnection API, WebRTC identity, and SDP/JSEP handling.
Owner: Byron Campen
Peer(s): Eric Rescorla, Adam Roach, Randell Jesup, Nils Ohlmeier
Source Dir(s): /media/peerconnection, /dom/media/peerconnection (see below)
Bugzilla Component(s): Core::WebRTC (Signaling)
Historically, the code for these two areas has been intermingled pretty
freely under /media/webrtc and /dom/media/webrtc. With this module
split, I also propose a directory reorganization along the following
lines, allowing for concise statements about which files go with with of
the proposed new submodules.
The WebRTC Signaling module would be constituted as follows:
* Move /media/webrtc/signaling/src/peerconnection => /media/peerconnection
* Move /media/webrtc/signaling/src/jsep => /media/peerconnection/jsep
* Move /media/webrtc/signaling/src/sdp => /media/peerconnection/sdp
* The signaling-related unit tests would move from
/media/webrtc/signaling/test into /media/peerconnection/test
* The PeerConnection-related files under /dom/media would move to a
new /dom/media/peerconnection directory. These include
/dom/media/PeerConnection.js, /dom/media/PeerConnectionIdp.jsm, and
/dom/media/webrtc/PeerIdentity.{h,cpp}
At the same time, the structure of the media-related code has evolved to
be quite deep and somewhat labyrinthine. I would propose we take
advantage of this restructuring to simplify as follows:
* The remaining directories under /media/webrtc/signaling/src would
move to /media/webrtc
* The remaining files in /media/webrtc/signaling/test would move to
/media/webrtc/test
There are some minor exceptions to these general moves (e.g.,
/media/webrtc/signaling/src/common/time_profiling/ would find a new home
under /media/peerconnection, and
/media/webrtc/signaling/src/peerconnection/Media* would end up under
/media/webrtc), but these exceptions should be obvious and rather
limited in number.
--
Adam Roach
Principal Platform Engineer
a...@mozilla.com
+1 650 903 0800 x863
___
governance mailing list
governance@lists.mozilla.org
https://lists.mozilla.org/listinfo/governance
Re: company-confidential or mozillian-confidential?
On 13/04/15 13:24, Gijs Kruitbosch wrote: > Can you give a few examples of the types of bugs where you believe > company-confidential is wrong and yet they can't be public? Example: IT bugs are private by default, presumably in case the bug or follow-up reveals some data about our internal systems. Those could be changed to anyone-with-an-nda. Gerv ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
Re: company-confidential or mozillian-confidential?
Yes, it would be time-consuming, but if it's not done then: a) leadership can't know how big of a problem Mozilla has with transparency, and how consistently or inconsistently different teams are applying guidelines as to what is private or isn't b) you're basically just suggesting we solve the problem as it affects you, rather than addressing it as a whole. Perhaps the word audit is conjuring up images that I don't mean to. I don't mean that a team should go through every single bug that is marked confidential. On Mon, Apr 13, 2015 at 1:39 PM, Benjamin Kerensa wrote: > That would be pretty time consuming to do an across the board audit. I > think the thing is Mozilla is a corporation at the end of the day and not > everyone it hires cares about the manifesto or open source and so working > in the open is not a priority and defaulting to corporate norms is > something that just happens. > > I've seen this happen where a employee who just started working in the > open leaves and is replaced by a new hire with a corporate background who > defaults the work that was already being done in the open back to closed. > > Anyways to the point of bugs I think their needs to be some criteria for > what should and should not be company-confidential. I think we need a new - > confidential group added as a less restrictive level and with criteria and > go from there. > > On Apr 13, 2015 10:17 AM, "Majken Connor" wrote: > > > > I'd love to see a formal audit. Like, have some team go through and > figure > > out where are all these policies, who does what in private and why do > they > > do it in private? I wonder if anyone in the organization has a complete > > view like this? > > > > I'm not opposed to things needing to be private, but it should be > > consistent, and it should be explained why it can't be. > > > > I think also if there were a group starting off with an audit, then that > > could also be the start of a group that helps try to "solve" for some > > things that we wish are public, but don't have a good plan around how to > do > > that well. > > > > On Mon, Apr 13, 2015 at 8:24 AM, Gijs Kruitbosch < > gijskruitbo...@gmail.com> > > wrote: > > > > > On 13/04/2015 05:46, Benjamin Kerensa wrote: > > > > > >> In the cases of things that truly need to be company-confidential then > > >> those could still be marked but unless a strong justification could be > > >> given for flagging company-confidential then > > >> > > >> bugs that would ordinarily be made company-confidential would be > > >> mozillian-confidential. > > >> > > >> Thoughts? > > >> > > > > > > Overall, I think we overuse company-confidential and I would prefer > that > > > more bugs became public. > > > > > > Can you give a few examples of the types of bugs where you believe > > > company-confidential is wrong and yet they can't be public? > > > > > > ~ Gijs > > > > > > ___ > > > governance mailing list > > > governance@lists.mozilla.org > > > https://lists.mozilla.org/listinfo/governance > > > > > ___ > > governance mailing list > > governance@lists.mozilla.org > > https://lists.mozilla.org/listinfo/governance > ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
Re: company-confidential or mozillian-confidential?
IT bugs are NOT private by default, but it is true that most of the time we click the "infrastructure" button, that means that it will be private. I know this because I am in IT. (Also, IT has a few different products, but for the ones I know about, only one has a default of private, and that's a legacy metrics product). On Mon, Apr 13, 2015 at 2:23 PM, Gervase Markham wrote: > On 13/04/15 13:24, Gijs Kruitbosch wrote: > > Can you give a few examples of the types of bugs where you believe > > company-confidential is wrong and yet they can't be public? > > Example: IT bugs are private by default, presumably in case the bug or > follow-up reveals some data about our internal systems. Those could be > changed to anyone-with-an-nda. > > Gerv > > ___ > governance mailing list > governance@lists.mozilla.org > https://lists.mozilla.org/listinfo/governance > -- -Sheeri Cabral Manager, Data Team at Mozilla File a bug for the Data Team - https://bugzilla.mozilla.org/enter_bug.cgi?product=Data%20%26%20BI%20Services%20Team Find the Data team on #data on irc.mozilla.org ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
Re: company-confidential or mozillian-confidential?
On 13/04/15 19:52, Sheeri Cabral wrote: > IT bugs are NOT private by default, but it is true that most of the time we > click the "infrastructure" button, that means that it will be private. To be clear, what I mean is, on this form: https://bugzilla.mozilla.org/form.itrequest (which I think is the normal non-IT way to file IT bugs) the "This is an internal issue which should not be publicly visible" checkbox is checked by default. Gerv ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
Re: company-confidential or mozillian-confidential?
On 13/04/15 05:46, Benjamin Kerensa wrote: > We are talking about radical participation this year as a organization > priority but there are still a lot areas of the project and to Mozilla > itself that are not visible to core contributors (I like to call it the > Great Wall of Mozilla) even those who are under NDA. I was recently > discussing how there is a prevalence to flag groups of bugs and types of > bugs as company-confidential by default when they could be open to core > contributors who are in the NDA Group. To add some data to the discussion, here are some numbers for groups in Bugzilla which aren't security groups (i.e. they don't conceal security bugs). All counts are total bugs, other than where indicated. Note that having a group in this list does not mean I think it should necessarily have its access permissions broadened. marketing-private: 381 metrics-private: 1,940 mozilla-confidential: 4049, of which 27 are open mozilla-employee-confidential: 10,000+, of which 1,973 are open, 10,000+ fixed (Bugzilla won't tell me how many; there's a 10,000 limit) mozilla-engagement: 889 mozilla-foundation-confidential: 17 mozilla-messaging-confidential: 0 mozilla-reps: 7301 pr-private: 0 privacy: 0 www-mozilla-org-confidential: 11 community-it: 22 consulting: 0 mozilla-confidential for many years early in the project was a catch-all group for things which needed to be hidden. For many years it was rarely used, but in mid-2013 it started to receive large dumps of obsolete bugs. It doesn't seem to be used much for live bugs, although the Data Compliance group seem to be using it. Automatic Memberships: mozilla-confidential automatically includes all Corporation, Foundation and Messaging employees, assuming they are members of the appropriate (non-bug) group. mozilla-employee-confidential automatically includes all Corporation, Foundation and Mozilla Japan employees. Gerv ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
Re: company-confidential or mozillian-confidential?
On 13/04/15 10:39, Benjamin Kerensa wrote: That would be pretty time consuming to do an across the board audit. I think the thing is Mozilla is a corporation at the end of the day and not everyone it hires cares about the manifesto or open source and so working in the open is not a priority and defaulting to corporate norms is something that just happens. I think that this happened in the past, but is no longer the case. However, I would like to request you to share more info on this, and if you feel that someone inside the org is acting that way, feel free to comment/complain. I'm not probably the best person to receive this feedback, but I think two names at the participation team (Brian, William Q), that could help you on that. Every single new hire has to go through a webpage, where you find clear information about how Mozilla operates, what the communities are, etc. So I think that the new employees are completely aware that we work in the open. Also the HR team is working hard to solve that gap constantly. I've seen this happen where a employee who just started working in the open leaves and is replaced by a new hire with a corporate background who defaults the work that was already being done in the open back to closed. Anyways to the point of bugs I think their needs to be some criteria for what should and should not be company-confidential. I think we need a new - confidential group added as a less restrictive level and with criteria and go from there. I was checking some of the "discussions" bugs, and there is no comment actually. I'm pretty sure that they don't use those bugs, however, it was implemented to have a track of the decision process. If you want, we can talk with Sandra, Jason and Dan to see if they want to share a doc with the criteria to select which events will support, etc. We can populate this doc through the DAM portal for example. Cheers, Franc.- On Apr 13, 2015 10:17 AM, "Majken Connor" wrote: I'd love to see a formal audit. Like, have some team go through and figure out where are all these policies, who does what in private and why do they do it in private? I wonder if anyone in the organization has a complete view like this? I'm not opposed to things needing to be private, but it should be consistent, and it should be explained why it can't be. I think also if there were a group starting off with an audit, then that could also be the start of a group that helps try to "solve" for some things that we wish are public, but don't have a good plan around how to do that well. On Mon, Apr 13, 2015 at 8:24 AM, Gijs Kruitbosch On 13/04/2015 05:46, Benjamin Kerensa wrote: In the cases of things that truly need to be company-confidential then those could still be marked but unless a strong justification could be given for flagging company-confidential then bugs that would ordinarily be made company-confidential would be mozillian-confidential. Thoughts? Overall, I think we overuse company-confidential and I would prefer that more bugs became public. Can you give a few examples of the types of bugs where you believe company-confidential is wrong and yet they can't be public? ~ Gijs ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance -- Francisco Picolini Community Events Coordinator @mozilla ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
