Closed Bug 330345 Opened 18 years ago Closed 14 years ago

Transparency: Open lists that are not business- or security-confidential

Categories

(mozilla.org :: Governance, task)

Product:
mozilla.org
Component:
Governance
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: zak, Assigned: gerv)

References

(
URL
)

Details

Brendan Eich writes:
... we should get rid of closed lists, except where they function for business-confidential reasons.
Adding Darin Fischer to Cc list.
Status: NEW → ASSIGNED
"not business-confidential or security-confidential"
I'd like to add that as much as possible, it would help transparency if mozilla.org stated clearlly what private lists exist and the purpose for their existance.

It is also important that members of those private lists self-moderate and move things over to public lists when appropriate.
Good feedback - thanks!

I have changed the summary to more accurately reflect the nature of the issue.
Summary: Transparency: Open lists that are not business-confidential → Transparency: Open lists that are not business or security-confidential
staff@mozilla.org has always been closed because we do discuss business-confidential things on it, and field mail from plaintiffs who think some subsidiary owner (module or project-management, aka driver) isn't doing right.  If I review staff mail over the last year from memory, perhaps half of it should be kept confidential (at least at first).  I'm going from memory here because of disk errors afflicting my Linux partition :-(.

Cc'ing shaver to get his thoughts.

/be
Summary: Transparency: Open lists that are not business or security-confidential → Transparency: Open lists that are not business- or security-confidential
I sent my thoughts in private mail.

No, I jest.  I am personally not as worried about staff@ as I am about drivers@, mainly because the latter's discussions seem to be dominated by things that should be public.  I recall the same generally about staff@'s conversations having a much larger proportion of conversations that were "appropriately private".

It's not just about subject matter that needs to be private, though.  For staff@ (but much much less so for drivers@ in my experience and opinion) I think it's often important for people to speak more candidly than they might be willing to in public -- not something that I personally have much problem with, perhaps unfortunately -- in order to effectively and honestly resolve conflicts and policy shifts.  What staff@ decides and why should generally be broadcast widely, I think, but having the actual conversation out in the open would not add much marginal value, and I think would have some very unpleasant costs.

I am obviously assuming a role for staff@ that might not indeed be the appropriate one, now that we have a Foundation and a Foundation staff; it's mostly a historical perspective, but whoever ends up dealing with that stuff and whatever the mailing list is called, I think the issue remains basically the same.
Shaver makes a good point I've made sporadically (Gerv's heard it, also most recently Fritz, who may think I'm a big curmudgeon): not everything is for one's outside voice.  People speak differently, sometimes more candidly, sometimes intemperately, in private (both modes have their uses).

Also, to communicate in an all-open, all-the-time fashion tends to leave one jabbering or slack-jawed.  Transparency != coherence.  All human communication of any significant content involves layered conversations.

Still and all, we should err on the side of transparency where it doesn't have costs we'd rather avoid.  It is ironic for us staffers to relive this kind of reform process, since we had a big fun time spearheading it with netscape.com back in the day.  Thanks to Ben and Darin for pushing it.

/be
zak: Please only change the assignee and not the QAContact when you are taking a bug. Many of us watch the QAContact for changes with Governance bugs, and by changing it, it causes bugmail to be lost and never seen. Thanks!
Status: ASSIGNED → NEW
QA Contact: zak → governance
Status: NEW → ASSIGNED
Closing this bug. 

Please file specific bugs requesting the opening (or closing) of specific lists.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → INCOMPLETE
Zak: how? Did Darin's comment 3 get addressed somewhere?

> I'd like to add that as much as possible, it would help transparency if
> mozilla.org stated clearlly what private lists exist and the purpose for their
> existance.

I doubt there is a good solution (and so I'm not reopening), since a public list of private lists with a blurb saying "contact list-ombudsman at mozilla.org if you think one of these lists should be public" would just result in uninformed noise, but since there's no way for anyone outside a private list (other than the famous ones like staff@ and drivers@) to even know it exists, effectively your resolution is not "Please file specific bugs" but "We trust the people on our private lists to make their own decision about whether or not they should be transparent."
During our (Frank, Gerv and I) rapid triage of bugs this morning, I missed that comment. Thank you for bringing it up.

What would the purpose of publishing list of private mailing lists be? As with public mailing lists, people often post off topic issues or discuss things in ad hoc lists created by Cc: groups.

Can people concerned about this issue elucidate what would be beneficial about such a list?
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
During our (Frank, Gerv and I) rapid triage of bugs this morning, I missed that
comment. Thank you for bringing it up.

What would the purpose of publishing list of private mailing lists be? As with
public mailing lists, people often post off topic issues or discuss things in
ad hoc lists created by Cc: groups. A list of private lists wouldn't necessarily correlate to a list of topics that are privately discussed.

Can people concerned about this issue elucidate what would be beneficial about
such a list?
"That's some catch, that Catch-22," he observed.

I have no way of evaluating whether or not drivers@ should have been opened, because I don't know what's said on it. I have no way of evaluating whether or not sensitive things that are discussed on it, if any, could or should instead be discussed on a security list, because while I know who's in the security group, I have no way of knowing what mailing lists they might have, whether there is only one with the published security group members or more than one with differing membership, or what overlap there is or isn't between security and drivers.

I have no way of knowing how much discussion on any of the private lists I know exist should instead be public, and I have no way of knowing what private lists I don't know exist should instead be public, or have too much discussion that could instead be done somewhere else public. I have no way of knowing what secret discussions I could contribute to, or what secret discussions would make me a more valuable contributor to the project if I could overhear them.

That's the basic nature of having secrets, and there's no way I can change it from the outside, I can only trust that the "natural hacker elite" that Brendan mentioned in the thread that started this bug can be counted on to at least try to limit their secrets to things that must remain secret, and to suffer through the noise of talking in public when they can. However, the one set of things kept secret from me that I have absolutely no problem with is the security group, and that's partly because I see the need, and partly because I know not only that the group exists, but who is a part of the group. But right now, I don't know whether we are talking about another five private lists, or five hundred, or whether the membership is mostly a few non-overlapping people, or a couple hundred people who all know everything that I don't know.

So, publishing a list of the private lists, particularly along with a list of their membership, would make me feel better about things, without really changing anything, but my real point was that you can close this bug by saying "we'll try to foster a culture of saying 'let's take this to a public list' whenever possible," but you can't close it by saying "if you want a private list you don't know exists to be public, file a bug asking that it be made public without knowing what it is, much less what's said on it."
Thanks for taking the time to elaborate. I'll admit to being both heavy-handed and arbitrary right now - we have a chunk of governance bugs that are getting little attention. Asking for feedback often turns up little response. Closing bugs helps encourage action. :)

Perhaps a basic approach of:
* Adopt a policy of, "Public by default, private if required"
* Open any lists that can be opened
* Note lists that won't be opened
* Make sure to update list pages and welcome messages so that people know when things are and are not private.

For extra bonus points and perhaps to complicate things overmuch, we could:
* Set disclosure dates for lists - ie. all security list posts will be revealed after X months.
* Run a script that posts list traffic statistics each week.
Does this bug have continued value? If people know of private fora which should be opened, please file a specific bug for each.

Gerv
Status: REOPENED → RESOLVED
Closed: 17 years ago → 15 years ago
Resolution: --- → FIXED
"That's some catch, that Catch-22," he observed.
Fixing to a more appropriate resolution: if we did not open any lists, and we will not publish a list of closed lists, and we will not assign someone to have access to every single closed list who will watch them for whether or not they need to be closed, then we fixed nothing, we chose instead to not fix anything. 

(Yeah, inva/wfm are possible resolutions, if absolutely every single closed list has a need to be closed, but if someone with access to every single closed list reviewed their reason to be closed and whether their content was overwhelmingly things that could be open, I think it likely they would have mentioned it in a comment.)
Resolution: FIXED → WONTFIX
(In reply to comment #15)
> Does this bug have continued value?

Zak's list in comment 14 seems to still have some actionable items:

> * Adopt a policy of, "Public by default, private if required"
> * Open any lists that can be opened
> * Note lists that won't be opened
> * Make sure to update list pages and welcome messages so that people know when
> things are and are not private.

We could start with publishing a "list of lists", as has been suggested. We don't even have to provide their actual email address, if spam/misuse is a concern - just a list of lists that exist and their membership/reason for existence. I could be wrong (maybe I'm not in the right club!), but I don't think there are any private Mozilla lists whose existence cannot be revealed. MoCo server-ops could help here.

Granted, encouraging debates about the necessity of specific private lists and having to justify their presence might be a time sink, but it seems like something that the project, the corporation and the foundation should be able and willing to do, at least to some degree.
Assignee: zak → nobody
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
OK. There's a slightly fuzzy line, of course (is the Mountain View office's "hey, there's this cool gig next week" list a private list of the Mozilla Project which we have to account for?) but in principle, I agree it's good for transparency if we have a list.

I wonder who could provide one. I'll file a bug in server ops asking for it to be mailed to me privately for assessment. After all, if there are no items on it, this bug can be closed :-)

Gerv
(In reply to comment #19)
> (is the Mountain View office's "hey, there's this cool gig next week" list a
> private list of the Mozilla Project which we have to account for?)

For the sake of simplicity it seems easiest to be inclusive of all Mozilla Corporation/Foundation-hosted lists. I don't really expect the existence of that specific list or others like it to be controversial, so the cost of including them should be near-zero. I hope I'm not wrong :)
I have a lot of the data for this, and the good news is that there seem to be very few lists which might cause concern. However, I need to get a bit more data out of mailman (which, each time I do it, requires mrz to run a script) before I can present it usefully for public consumption.

Gerv
Assignee: nobody → gerv
Based on the initial analysis, we decided this was not a big problem. But we will revisit it periodically.

Gerv
Status: REOPENED → RESOLVED
Closed: 15 years ago → 14 years ago
Resolution: --- → FIXED
Is that analysis public somewhere?
No. I don't know who I'd have to ask to get permission to publish the list of private mailing lists...

Gerv
I didn't realize that publishing the existence of private lists was something that needed permission. If the lists are protected properly, being published won't matter. If they aren't, it's security through obscurity anyway, which is a much bigger problem. But hey, what do I know?
(In reply to comment #25)
> I didn't realize that publishing the existence of private lists was something
> that needed permission. If the lists are protected properly, being published
> won't matter. If they aren't, it's security through obscurity anyway, which is
> a much bigger problem. But hey, what do I know?

I'd like to publish the list, but "publish and be damned" is not my style, and precisely because it didn't seem like a big problem, it's not a high priority to work out how to do it.

If there are private lists you know of that you think need to be opened up (which is the point of this exercise), then let me know. 

Gerv
"That's some catch, that Catch-22," he observed.
Resolution: FIXED → WONTFIX
(In reply to comment #26)
> I'd like to publish the list, but "publish and be damned" is not my style, and
> precisely because it didn't seem like a big problem, it's not a high priority
> to work out how to do it.

It doesn't seem like a problem for you, but you've seen the data. To those who haven't seen the data, it could be a huge problem... or not. There's no way to know, which I thought was part of the point of this bug.

> If there are private lists you know of that you think need to be opened up
> (which is the point of this exercise), then let me know. 

Did you really not read this bug? Comment 13? But fine, let's WONTFIX it.
You need to log in before you can comment on or make changes to this bug.