company-confidential or mozillian-confidential?

[Benjamin Kerensa]

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.

As an example, by default, when you file a request for support of an event
to Developer Engagement, those requests now generate two bugs. One for
tracking and another for discussion (which is done in private and flagged
company-confidential.) I could give plenty of other examples but because
this is a public mailing list it would reach into areas I am not allowed to
discuss on a public mailing list.

That said, I think our use as a project and as an organization of
company-confidential is overzealous and often times does not promote the
transparency or working in the open that our manifesto envisions.

So I am suggesting we discuss this here and on Moz Governance some. One
idea that was suggested to me by Gerv was the idea of having a
mozillian-confidential flag that employees and NDA contributors are added
to and that we move towards defaulting to this more often.

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?

[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

[Majken Connor]

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 <gijskru...@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
> gover...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/governance
>

[Benjamin Kerensa]

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" <gijskru...@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?
>
>

[Gijs Kruitbosch]

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

[Benjamin Kerensa]

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" <maj...@gmail.com> 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 <gijskru...@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?
> >>
> >

[Benjamin Kerensa]

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" <gijskru...@gmail.com>
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:
>>

[Gervase Markham]

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

[Majken Connor]

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 <bker...@gmail.com>
wrote:

> > On Mon, Apr 13, 2015 at 8:24 AM, Gijs Kruitbosch <

> gijskru...@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?
> > >

[Sheeri Cabral]

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 <ge...@mozilla.org> 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
> gover...@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

[Gervase Markham]

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

[Gervase Markham]

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

[Francisco Picolini]

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" <maj...@gmail.com> 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 <gijskru...@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
>>> gover...@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/governance
>>>
>> _______________________________________________
>> governance mailing list
>> gover...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/governance
> _______________________________________________
> governance mailing list
> gover...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/governance

--

Francisco Picolini
Community Events Coordinator
@mozilla

[Pascal Chevrel]

Le 13/04/2015 06:46, Benjamin Kerensa a écrit :
> 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.
>

> [...]
>
> Thoughts?
>

Hi,

I have to deal regularly with bugs marked as employee confidential,
mostly marketing ones. Here is what I noted:
- some employees mark all of their bugs as employee confidential, I am
guessing that they are using one of these simplified forms that have
that option by default
- sometimes, bugs are marked as 'security confidential' when they should
be marked as 'employee confidential'
- The confidentiality of these bugs is related to a partnership and
usually an announcement on our web parts of something done with
partners, that can be for example a bug with screenshots where you can
see a Firefox OS partner logo. When the information becomes public, the
confidentiality flag is not removed while there is nothing secret anymore.

As I work with localizers who are volunteers, it can be annoying because
they can't see the content of the bug, yet they are supposed to
translate stuff that is described in the bug, which means that we have
to CC manually trusted localizers to the bug, which also means that it
is often the same localizers that have to work on this urgent stuff
(when it involves partners, it always comes late because of legal
reviews and there is always an additional dosis of stress involved ;) ).

The concept of a wider range of confidential bugs that would give access
to trusted mozillians is interesting, that's the kind of more granular
rights that you can see in CMS. It could also add another level of
complexity though.

What personnally I'd like to see happening is two things:
1/ A reason in the bug description why this bug was marked as
confidential ('Marking this bug as employee confidential because it
contains infrormation that we don't want to be public before date x" for
example).
2/ See all bugs marked as employee confidential get this flag removed
when the reason makes no sense anymore (new secret product launched in
market X, anouncement of a partnership now everywhere in the press...)
3/ On the simplified forms, have a separate field where the employee
explains why a bug is confidential and append this explanation to the
bug description in comment #0

Cheers

Pascal

[Pascal Chevrel]

Le 14/04/2015 11:27, Pascal Chevrel a écrit :
> Le 13/04/2015 06:46, Benjamin Kerensa a écrit :
>> 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.
>>
>> [...]
>>
>> Thoughts?
>>
>

>

> What personnally I'd like to see happening is two things:

And yes, I actually listed three things, need moaaarr coffee :)

Pascal

[Gijs Kruitbosch]

Prefix: in my opinion, ...

On 13/04/2015 18:44, Benjamin Kerensa wrote:
> Operational:
> - Financial

It is not clear to me what the benefit of making these open to
volunteers is when this regards moco (office) finances. Things like "we
need to pay X dollars to vendor Y for the coffee machine / EV-recharging
parking place / light fittings / bikes / ..." seem like things that are
tiny details of MoCo finance that wouldn't really benefit from volunteer
involvement. I'm not sure why they're even on bugzilla to begin with.

Don't get me wrong: we have a responsibility to do finances openly and
that includes publishing details of our year-end financial data and what
got spent on what in overall terms. AIUI that doesn't mean per-item
spending should be public (and sadly, there are significant downsides to
making that public, e.g. if you negotiate with a vendor about doing task
X and they can see that you paid Y for it before, nobody will offer you
less than Y because that would be stupid...).

> - Marketing

More/most of these should be public.

I don't understand why it would be acceptable to simply enlarge the
"in-crowd" for these bugs. It satisfies the volunteers under NDA, but
nobody else. We should just be more open.

> - Events

What kind of bugs are these? In general, I am not sure why events bugs
wouldn't be open unless they are essentially financial bugs ("we need to
pay X to hotel Y for hosting/catering this workshop/press event") for
which see above. For everything else, I'm not sure why they shouldn't be
public.

> - Some roadmap/product bugs

These should be public.


FWIW, with this set of bugs, it sounds a lot more like "I would like to
equalize the field between NDA'd volunteers and employees regarding bug
access" than "I believe in radical openness and we should be applying it
to bugzilla".

This is not intended as a sleight; both of these are valuable goals
(though I'd argue the second is more valuable). But you presented the
second argument in order to do something which, AFAICT, really only
satisfies the first. The number of volunteers with signed NDAs is pretty
limited and I don't see how opening up events/finance bugs just to them
is useful beyond aforementioned equalizing between volunteer and
employee community members (which, again, is perhaps a reasonable goal,
but not the one you cited in support of asking for this).

If we're going to try to be more open, let's be more open, and not
half-closed still. :-)

~ Gijs

[Robert Kaiser]

Benjamin Kerensa schrieb:

> Not publicly no :) and that's why I suggest a nda-confidential or
> mozillians-confidential.

FWI, I support the idea of replacing mozilla-employee-confidential with
nda-confidential.

KaiRo

[Mike Connor]

I get the sentiment, but that's just not practical in all cases. Not
everything we can share with employees can be shared with community
members, signed NDA or no. That's the reality of commercial partnerships,
and it's simply not viable to demand that every potential partner share our
bias toward openness.

That said, Bugzilla is not the right level to have this discussion. How we
control/grant access to sensitive information should be the subject of
overall policy and guidance that applies across all systems and groups. We
must balance risk and reward in terms of who we share information with,
especially for any information involving partners. There are people looking
at creating a clear taxonomy for dealing with various forms of sensitive
information (primarily tied to partnerships and our legal obligations
therein), which I consider to be an important prerequisite for any
discussion about bug groups or implementation details.

I strongly agree with the sentiment that we should strive to be more open
where possible and where openness will help us collectively act in the
interests of the mission. My belief is that's going to be a much easier
conversation to have once we have a workable taxonomy we can look at and
discuss. Given that, I'd like to propose that we table this conversation
until that taxonomy is ready for discussion.

-- Mike

On 14 April 2015 at 16:06, Robert Kaiser <ka...@kairo.at> wrote:

> Benjamin Kerensa schrieb:

>
>> Not publicly no :) and that's why I suggest a nda-confidential or
>> mozillians-confidential.
>>
>

> FWI, I support the idea of replacing mozilla-employee-confidential with
> nda-confidential.
>
> KaiRo
>

[Gervase Markham]

On 14/04/15 21:47, Mike Connor wrote:
> I get the sentiment, but that's just not practical in all cases.

Sure. So let's evaluate each case and see where it is practical. I'm
fairly sure it is practical in at least some of the cases under discussion.

> That said, Bugzilla is not the right level to have this discussion. How we
> control/grant access to sensitive information should be the subject of
> overall policy and guidance that applies across all systems and groups. We
> must balance risk and reward in terms of who we share information with,
> especially for any information involving partners. There are people looking
> at creating a clear taxonomy for dealing with various forms of sensitive
> information (primarily tied to partnerships and our legal obligations
> therein), which I consider to be an important prerequisite for any
> discussion about bug groups or implementation details.
>
> I strongly agree with the sentiment that we should strive to be more open
> where possible and where openness will help us collectively act in the
> interests of the mission. My belief is that's going to be a much easier
> conversation to have once we have a workable taxonomy we can look at and
> discuss. Given that, I'd like to propose that we table this conversation
> until that taxonomy is ready for discussion.

Is there an identified group working on this taxonomy? Is it part of
their quarterly goals? Are there ways to track their progress, and
provide input into their workings?

(Without those things, all the above runs the risk of sounding like
"We're going to apply stop energy to this improvement because we are
doing a bigger change which may actually never happen.")

Gerv

[Benjamin Kerensa]

> > I strongly agree with the sentiment that we should strive to be more open
> > where possible and where openness will help us collectively act in the
> > interests of the mission. My belief is that's going to be a much easier
> > conversation to have once we have a workable taxonomy we can look at and
> > discuss. Given that, I'd like to propose that we table this conversation
> > until that taxonomy is ready for discussion.
>

> Is there an identified group working on this taxonomy? Is it part of
> their quarterly goals? Are there ways to track their progress, and
> provide input into their workings?
>
> (Without those things, all the above runs the risk of sounding like
> "We're going to apply stop energy to this improvement because we are
> doing a bigger change which may actually never happen.")
>

I would add are these taxonomy discussions open to Mozillians under NDA?
Can other staff who
might be interested participate?

[Mike Connor]

The vast majority of the work is evaluation of legal compliance (i.e.
financial, people, contractual, etc) to identify how restrictive we _must_
be in order to be compliant with our legal obligations. That part is not
going to be open, as many of the details can't or shouldn't be shared. Once
we've established what we _must_ do, it's easier to have a conversation
about what we _should_ do within that framework.

On 15 April 2015 at 05:37, Benjamin Kerensa <bker...@gmail.com> wrote:

>
> > I strongly agree with the sentiment that we should strive to be more open
>> > where possible and where openness will help us collectively act in the
>> > interests of the mission. My belief is that's going to be a much easier
>> > conversation to have once we have a workable taxonomy we can look at and
>> > discuss. Given that, I'd like to propose that we table this
>> conversation
>> > until that taxonomy is ready for discussion.
>>

[Gervase Markham]

On 15/04/15 16:54, Mike Connor wrote:
> The vast majority of the work is evaluation of legal compliance (i.e.
> financial, people, contractual, etc) to identify how restrictive we _must_
> be in order to be compliant with our legal obligations. That part is not
> going to be open, as many of the details can't or shouldn't be shared. Once
> we've established what we _must_ do, it's easier to have a conversation
> about what we _should_ do within that framework.

Is there an identified group working on this taxonomy? Is it part of

their quarterly goals? Are there ways to track their progress?

Gerv