[Tinyos-alliance] Steering com input

[Ramesh Govindan]

David E. Culler said the following on 4/25/2006 11:19 AM:
 > Ramesh
 >   Would you like to draft a revision to that section of the tep.
 >

David, Phil,

I took the liberty of making a pass over the entire Section 4, making 
mostly minor changes along the way. I have attached the completed revised 
section below.

My main contribution was to replace the earlier paragraph about SC 
approval of architectural TEPs with this (please feel free to rewrite):

The SC is also responsible for reviewing and approving all TEPs. WGs
submit TEPs to the SC for review. The SC should appoint one
contributing Alliance member not affiliated with the corresponding WG
to review the TEP. This reviewer, who may or may not be a member of
the SC, may solicit comments from the community at large, but must
also thoroughly review the submitted TEP. WGs must address any
issues/questions brought up either by the reviewer or by other
community members. Once the reviewer approves the revisions, he/she
presents the TEP to the SC for approval by rough consensus. Finally,
TEPs that affect the organizational structure of the Alliance must
also be approved by the Board.

I also had a couple of questions. Where we say:

Finally, the Steering Commitee will be responsible for determining the
procedural elements of the Alliance. This includes election
procedures, membership criteria, selection of venues, oversight of
access to code repositories and Alliance web sites, and regular
Alliance meetings.

<<Shouldn't the Board be responsible for some of these? For
example, election procedures and membership criteria might fall within
the purview of the Board?>>

Where we say:

The non-profit will require a Board of Directors responsible for
corporate matters.

<<RG: Do we need to say more here about what the Board does?
I don't see this discussed elsewhere in the document.>>

--------------- Revised section 4 --------------------------

4. Organizational Structure
====================================================================

The Alliance has a technical advisory function: guide the evolution of
the TinyOS architecture, formulate and track progress of working
groups, etc.

It also has an organizational advisory function: manage industry
interaction, legal and IP issues, evolution of the organization
itself, membership issues and so on.

We advocate an approach that starts small and grows the structure as
needed. The focus should be on the working groups. Working groups are
not limited to technical functions; they can be formed to promote
developments, markets, etc. Beyond the working groups, the
organization should remain lean, relying primarily on volunteers. We
want to avoid creating a situation where the organization becomes
focused on its own growth and pre-eminence at the expense of the
larger community and technical agenda.

Technical directions should be driven by merit and overall soundness,
consensus building.

The Alliance will consist of a non-profit corporation with a Board of
Directors, a small support staff (primarily volunteer or outsourced)
and a Steering Committee. The Steering Committee oversees a collection
of Working Groups, each with a Chair and Members.

Steering Committee
------------------

In the steady state the Steering Committee will consist of the chairs
of working groups plus a handful of elected members at large. Tenure
of a position on the Steering Committee will consist of two years with
opportunity for renewal. We want to see a vibrant, engaged, and
constantly evolving leadership while allowing for long-term and
committed members.

Initially the steering committee would be formed from working group
chairs plus some subset of the Alliance working group members.  This
initial committee will be responsible for putting in place the
membership and elections processes, which will then be utilized to
form the regular Steering Committee.

The primary role of the Steering Committee (SC) is to oversee the Working
groups (WG). This means establishing WG policy, providing appeals
process, managing WG creation/extinction, arbitrating between WGs, and
supervising activities to resolve conflicting directions and moving
the process towards overall architectural coherence.

The SC is also responsible for reviewing and approving all TEPs. WGs
submit TEPs to the SC for review. The SC should appoint one
contributing Alliance member not affiliated with the corresponding WG
to review the TEP. This reviewer, who may or may not be a member of
the SC, may solicit comments from the community at large, but must
also thoroughly review the submitted TEP. WGs must address any
issues/questions brought up either by the reviewer or by other
community members. Once the reviewer approves the revisions, he/she
presents the TEP to the SC for approval by rough consensus. Finally,
TEPs that affect the organizational structure of the Alliance must
also be approved by the Board.

Finally, the Steering Commitee will be responsible for determining the
procedural elements of the Alliance. This includes election
procedures, membership criteria, selection of venues, oversight of
access to code repositories and Alliance web sites, and regular
Alliance meetings.

Working Groups
--------------

The core of the alliance will be the working groups. Each working
group will have a chair who will be responsible for WG processes,
reporting, meetings, and membership. Working groups and their
functions are discussed in more detail in a later section.

Board of Directors
------------------

The non-profit will require a Board of Directors responsible for
corporate matters.