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
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 shou
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 - c
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
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 tha
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 underst
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 t
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
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 p
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
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 t
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
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 d
13 matches
Mail list logo
