The OPeNDAP community process and OPeNDAP Working Groups

[Patrice Dumas]

On Fri, Mar 23, 2007 at 02:49:17PM -0600, Peter Fox wrote:
> 
> Please send comments to me or discussion to opendap-dev.

Hello,

I am not exactly an opendap developer, but I have some experience
on how things work in the fedora project, maybe some ideas are of
relevance here. Instead of many working groups, there is (this is
simplified and adapted):

* a board: it takes the 'political decisions'. very few people in it.
* a technical commitee: people submit proposals, and there are voted
  upon by the other members of the technical commitee.
  All the people in this commitee are respected developpers/designers,
  nominated by cooptatio. The board can also veto or add members.
  Proposals are put on the wiki and sent on the list (cut and pasted)
  they are updated during the discussion.
  When they feel that this is not a technical issue, but a political 
  one, they ask the board.

Given the size of opendap, I think that all the discussions of these
bodies should happen on the opendap-tech mailing list.

* the community: people react on the proposals and may discuss,
  but cannot vote nor take 'political' decisions.

Political is in a specific meaning, it means something like big 
directions. 

This is not very different from what is on
http://docs.opendap.org/index.php/Formulation_of_Working_Groups
except that everything goes only through one public channel and there
is only one working group, but people decide to participate in
discussion only if they feel they are interested.

Experience shows that in fact there is very few people really active
in the community, so it is not very usefull to have more than one
group, it creates unhelpful barriers. Moreover some people from 
the community that are not interested in most of the issue may 
sometime be specialized on a particular point so it may be interesting 
to have the community listening to most of the discussions.

If it happens that some topics discussed by the technical commity
overflow opendap-tech, there could be a split of the list:
opendap-tech for what is today opendap-tech
and
opendap-?list? for the technical commitee list. Everybody may be 
subscribe to be on the opendap-?list? mailing list, and everybody 
may comment on the issues, only members of the commitee may vote.

The OPeNDAP working groups are, in my story, a proposal discussed on
the list. Therefore, for each of the points in 
http://docs.opendap.org/index.php/Working_Groups
somebody should put up a proposal and send it to the list for 
discussion (and at the same time put it in the wiki).

Also, in my opinion, software, or technical documents don't need 
specific working groups, they just need to be done by developpers. 
Code is already public in svn, no need of more. Patches may be sent 
to the list, or in private when there is clearly a maintainer, but, 
in my opinion, a working group wouldn't be that helpful. (discussion
about the code design may be held by the technical commitee, but 
no actual code).

Lastly there may be irc meetings for the technical commitee members
held with a schedule defined by advance, send to the list such that
people from the community may react on it. Each item of the schedule
should be associated with a person in charge of animating the
discussion. The logs and a summary are posted to the list and the wiki.

Sometime a topic becomes so important that it deserves a specific
mailing list. In that case that mailing list is created, and corresponds
with a Working Group in
http://docs.opendap.org/index.php/Formulation_of_Working_Groups
But this should only happen if the topic is prone to endless
controversies, in general, and -- in my opinion -- given the size of
the opendap community having everything discussed on one mailing list 
is better.


As a disclaimer, I don't have other experience, and I don't really
know the OPeNDAP community in real, maybe all I say is not relevant,
you have been warned...


Also this is only manageable if threads are used in mail clients,
since the threads are the working groups. I have seen some webmail
poorly supporting threads, but this shouldn't be a show stopper.

--
Pat