[Foundation-l] Internal wiki(s) and confidential committee communications

[Erik Moeller]

I apologize for taking this out of the communications committee thread; 
however, I think this is an issue which affects all committees and 
should be discussed separately: How to deal with confidential information?

Daniel Mayer has rightly pointed out the risk of balkanization of our 
communications infrastructure. The current approach -- one wiki and 
mailing list for a lot of trusted people -- has the clear advantage that 
we can get input on a variety of issues from a reasonably large group of 
individuals.

Right now, being a member of the internal wiki and internal-l is tied to 
organizational status: board members and officers of the mother 
organization and its chapters have access. This is not entirely fair, as 
being a chapter officer doesn't automatically mean you're doing as much 
work, or have as much legitimate interest, as someone who does not 
currently have the required organizational status, and there is no 
process -- as far as I am aware -- for those who don't have it to gain 
access.

My favored approach would therefore be one which makes a clear 
distinction between the "core committees" (created through  Board 
resolutions) and the subcommittees (created by the committees 
themselves). To my knowledge, we have never really defined what a 
subcommittee is, so here is a hypothetical model:

1) A core committee which chooses its own members, using 75% approval 
(the steward threshold). If it is considered necessary, these members 
might also have to be approved by the Board majority or the Executive 
Committee; I would prefer this not to be the case. All these members 
have access to the internal wiki and list as they currently exist.

Membership status might be re-evaluated regularly. The committee members 
would be advised to choose only individuals who are already trusted to 
be granted access to confidential information, rather than those who 
have yet to earn that trust.

In addition, there are the observers/consultants, who can participate in 
open meetings, but do not have access to confidential information. 
Ideally, as much as possible should be discussed in open meetings, but 
how much that can be will vary, of course. Having these non-voting, 
non-member participants on board ensures that we have a constant 
pressure for openness, which is good, as it is always easy to become 
complacent and do things confidentially when you don't have to.

2) A subcommittee focusing on a particular area of interest, e.g. one 
project ("Wiktionary"), task ("OTRS") or language ("Swedish"). These 
could have their own membership procedures, i.e. be totally open or more 
restrictive, with the maximal restrictiveness being the same as the core 
committee. Being a member of a subcommittee alone would not 
automatically give you full access to the internal wiki and list. 
However, one could be a member of both a core committee and a subcommittee.

I would imagine that in practice, much of the work will be going on in 
focused subcommittees. I would also imagine that, due to them being 
generally more open, they will have less authority to act in the name of 
the Foundation than the core committees, but that they will be able to 
propose resolutions to the core committees.

So, in this model, members of the core committees would ideally be 
chosen based on them doing good work in the subcommittees, hence moving 
more to a meritocratic model of information access than the current one, 
which is tied to the (rather stagnant) organizational status.

Now, each of these subcommittees may have the need for confidential 
communications, and this is where it gets tricky. Here, I would suggest 
exploring the use of namespaces on the internal wiki to segregate 
confidential information relevant only to one subcommittee. For example, 
an OTRS: namespace could be created on internal.wikimedia.org 
particularly for the OTRS subcommittee of Communications.

This would necessitate changing the software to allow for namespaces to 
be associated with user groups, and then giving the correct group 
membership to everyone who is supposed to have access to the information 
relevant to a subcommittee. Hiding page content is not too hard; it gets 
a bit more complicated if we want to make sure that people cannot even 
see page _titles_ outside their given namespace access, as these are 
currently shown all over the place. Perhaps a gradual implementation 
would be sufficient.

I prefer this approach to creating lots of separate wikis because, for 
those people who are trusted to see _all_ confidential information, it 
reduces the need to manually aggregate information from lots of places 
(balkanization), and enables them to quickly get involved in relevant 
discussions (synergies). At the same time, it guarantees that people who 
have not yet gained the trust of a core committee cannot see anything 
which is not clearly relevant to them.

I know solutions involving software changes are always the least popular 
;-), but perhaps it is still preferable to ending up with 30 new wikis 
and mailing lists.

What do others think about this model? I hope we can discuss this in 
some more detail at the open meeting later today.

Best,

Erik