Documentation
    Getting Started
    TinyOS 2.0
    Hardware

Support
    FAQ
    Mail List Archives

Development
    Working Groups
    Sourceforge CVS
    Report a Bug
    Contributing Code

Community
    TinyOS Alliance (PDF)
    Mailing Lists
    TTX
    TinyOS Projects
    User Statistics
    Job Postings
    TinyOS 1.1 (no active support)

Active
TinyOS TinyOS Alliance Working Group (alliance)
TinyOS Core Working Group (core)
TinyOS Network Protocol Working Group (net2)
Sensor Network Testbed Working Group (testbed)
Sensor Simulation Working Group (sim)
Storage Working Group (storage)
TinyOS 8051 Working Group (8051)
TinyOS Tools Working Group (tools)

Recently Active
TinyOS 1.2 Working Group (tos1.2)

Completed
TinyOS Host Mote Working Group (host-mote)

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.

The TinyOS Alliance Steering Committee (SC) reviews proposals for the formation of new working groups, which should be sent 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 will 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.
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.

Here is an example of what a proposal from net2 might look like if written in November 2006.

Working groups define the difference between what code is in tinyos-2.x-contrib 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.