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
No IT/Ops makes sense much like sec bugs do.
On Apr 13, 2015 10:34 AM, "Gijs Kruitbosch" <[email protected]>
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" <[email protected]>
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
[email protected]
https://lists.mozilla.org/listinfo/governance
_______________________________________________
governance mailing list
[email protected]
https://lists.mozilla.org/listinfo/governance
