[Tinyos-devel] Working Group Formation

[Philip Levis]

The TinyOS Alliance provides a structure for individuals to become  
involved in the effort to establish and provide open code and  
protocols for embedded sensor networks. Working groups (WGs) are a  
major part of this structure. Working groups provide a forum for  
interested individuals from many different institutions and  
perspectives to collaborate on a common goal.

Currently, there's a very small number of working groups that are  
focused on basic services and abstractions: sensing, timers, packet  
communication, collection routing. This narrow focus was intended to  
make sure that there is the basic functionality that almost every  
application depends on. Now that TinyOS 2.0 (T2) has been released,  
there is a stable, well-documented core OS. It will undoubtedly  
evolve a bit, but the core abstractions are there; some of them have  
been tested and in use for two years. You can find a list of active,  
recently active, and completed working groups at

http://www.tinyos.net/scoop/special/working_groups

One of the major goals of T2's organization is to make it easier to  
add new modules and functionality. Therefore, the TinyOS Alliance  
Steering Committee (SC) is now ready receive proposals for the  
formation of new working groups. I've personally spoken with a few  
people who have expressed interest in forming groups on topics such  
as storage, simulation, and documentation. Send proposals to David  
Culler, the chair of the Alliance Working Group (culler AT eecs DOT  
berkeley DOT edu).

Working group proposals need not be long or verbose. Usually, a  
single page will do. A proposal should have 6 key pieces of information:

1) Name: the proposed name of the working group

2) Charter: 1-3 sentences describing the scope and topic the group  
wishes to work on

3) Members (and initial chair): A list of at least 3 people who will  
form the initial membership, as well as one additional person who  
will be the chair. The member list should include affiliations. While  
not a requirement, the SC strongly encourages that the initial member  
list include multiple perspectives. Working groups bring people  
together to work on a topic collaboratively; ideologically exclusive  
groups are contrary to this goal.

4) Membership policy: A description of what process the group will  
use to admit new members. This can vary from group to group: core is  
based on consensus, net2 is voting, and alliance is invitation (due  
to the fact that it will close as soon as it completes its work of  
bootstrapping the Steering Committee).

5) Timeline: A description of the planned work products for the first  
six months or so. The purpose of the timeline is not to be a set of  
hard deadlines, rather to give more detail on the group's output  
goals as well as a general metric the group can use to assess its own  
progress. The timeline doesn't need to be aggressive.

6) Overlap and Interactions: This identifies where and how work under  
the charter might overlap those of other working groups and how the  
new group plans to work with others.

Working groups define the difference between what code is in  
tinyos-2.x-contrib[1] and what code is in tinyos-2.x. A working group  
that includes implementations are part of its charter has one or more  
directories in the tinyos-2.x/ tree (generally but not always in tos/ 
lib and doc/). Each directory is "owned" by a working group, who  
develops, improves, and maintains the code and documents therein. A  
working group confers with the core working group on how to name and  
were to put these directories. Generally, directories are created  
once a WG has files to check in, rather than when the WG forms.

If net2 were to write a proposal, it might look like the text below.

Name: Network Protocols (net2)

Charter: To define interfaces and interoperability requirements for  
basic network (multihop) protocols and develop reference  
implementations of those protocols.

Members:

Rodrigo Fonseca, UC Berkeley (chair)
Jan Beutel, ETH Zurich
Henri Dubois-Ferriere, EPFL
Omprakash Gnawali, USC
Jonathan Hui, Arch Rock
Kyle Jamieson, MIT
Sukun Kim, UC Berkeley
Philip Levis, Stanford
Geoff Mainland, Harvard
Joe Polastre, Moteiv
Arsalan Tavakoli, UC Berkeley
Gilman Tolle, Arch Rock
Martin Turon, Crossbow
Ning Xu, Crossbow

Membership Policy:

The WG follows an Apache-style voting policy. Someone who wants to  
join emails the chair. The chair calls a vote. Each member can vote  
-1, 0., or +1. For someone to join, they must have a positive vote  
total and at least 3 members must have voted.

Timeline:

Nov 2007: Measure/identify causes of loss in CTP under medium load
Dec 2007: Define CTP rate control algorithm for heavy load (workshop)
Feb 2007: Begin discussion and evaluation of dissemination (TEP 118)
Mar 2007: Present CTP specification (TEP 123) and collection (TEP  
119) to SC for community review
Apr 2007: Initial implementation of link-layer API

Overlap and Interactions:

The boundary between net2 and core is the single-hop packet  
interface. net2 plans to work closely with core to define this  
interface, as it has requirements from protocols above (net2) as well  
as the hardware capabilities below (core). net2 has already brought  
this issue up with the core working group, who have agreed.

Phil

[1] The caretakers of tinyos-2.x-contrib (Kevin Klues and Martin  
Leopold) are hashing out some of the final details today. They will  
be putting information on www.tinyos.net and sending a message to - 
devel and -help next week.