[Tinyos-devel] Request for comments: TEP-108

[Matt Welsh]

There is a clear tension here between having TEPs that are so  
'finalized' that the authors are unwilling to respond to comments,  
and TEPs that are not fleshed out enough to discuss in detail. In  
some sense a TEP that is in community review has reached a point of  
maturity that it is unlikely that major changes will be made. By the  
same token there is nothing stopping someone who disagrees with a TEP  
from doing their own TEP with a competing approach. In fact I think  
we want to encourage this.

I think it is the job of the shepherd to ensure that the authors are  
responsive to feedback on the TEP. It is like getting a paper into a  
conference: acceptance is subject to shepherding, which is a process  
of compromise between the comments and the need to minimize overhaul.



On Nov 7, 2006, at 11:22 PM, Philip Levis wrote:

>
> On Nov 7, 2006, at 9:24 AM, Neil Hancock wrote:
>
>> To the TinyOS 2.0 core group
>>
>> Congratulations to the  TinyOS 2.0 working groups. A truly amazing
>> achievement to get the next level of functionality released, and  
>> hopefully
>> working. I don't see any pointers to test data in the release  
>> notice - but
>> hopefully everybody has done their best and had fun with it.
>>
>> However it does raise a question that I asked earlier and I feel I  
>> should
>> ask again:
>>
>>      What is the purpose of the Tinyos-devel TEP community review  
>> requests?
>>
>> It seems to me that the TEP community reviews are happening at a  
>> late stage
>> in the project cycle.
>>
>> I initially volunteered to review TEP-108, and haven't done it due  
>> to being
>> snowed under in other areas.
>> I have reviewed other TEPs and my sense of the TEP review's that I  
>> offered
>> was that even with some really basic comments, the TEP review is  
>> so late in
>> the project cycle that the authors don't feel able to incorporate  
>> anything
>> more.
>>
>> I don't propose to respond to TEP review requests unless it is  
>> clear that
>> the TEP review is early in the project cycle, that the TEP hasn't  
>> already
>> been implemented and there is a clear intent to seek community  
>> input to
>> shape the TEP.
>>
>> It could also be a failing in the TEP life cycle. That the  
>> documents are
>> "dead" documents and can't evolve once they are release.
>> Another possibility in the TEP life cycle is that the TEPS are living
>> documents, with multiple reviews and releases and define phases,  
>> so that the
>> implementation can be phased.
>>
>> Keep up the good work - it is virtually impossible to do  
>> everything right
>> straight away, so trial-and-error has to be built in.
>
>
> Neil,
>
> These are good points. Thanks for bringing them up.
>
> You're definitely right that many of the TEPs emerging now are  
> relatively late in their development cycle. It's commonly the case  
> that a given TEP has gone through 2-3 rewrites (and re- 
> implementations) before being sent to the Steering Committee for  
> community review. In that way they are living documents, which have  
> been in the repository, whose discussion has been on the publicly  
> accessible mailing lists, and whose re-implementations have been in  
> the repository.
>
> We tried sending a few earlier (e.g., 106 in March, 101, 106, 107,  
> 109 in July 2005). There were some comments, which were  
> incorporated into the documents. TEP 103, for example, had  
> significant feedback which was incorporated into the finalized  
> document. If you look carefully, the interfaces in TEP 103 are  
> different from those initially presented for community review.
>
> Unfortunately, the idea that a Documentary TEP might be seriously  
> considered *before* an implementation exists is a bit contrary to  
> the intent of that class of TEP. There may not be a full  
> implementation, but the general approach has been to at least have  
> prototypes as well as prototype users, in order to assess whether  
> the interfaces are feasible. Otherwise we get into a situation of  
> lots of people suggesting changes whose unforeseen ramifications  
> and difficulties others have to deal with.
>
> Ultimately, the purpose of the TEP review process is for the  
> authors to gain feedback from the community on their design  
> decisions. The most extreme case of this is finding bugs and  
> fundamental technical problems; lesser cases include unclear  
> specifications and wordings. Ultimately, it's up to the shepherd  
> and the authors which comments make their way into the TEP. If  
> other developers feel that the TEP is unsalvageable and a  
> completely different approach is needed, then it's always possible  
> to write a TEP about a different approach.
>
> TinyOS's component model is open to having multiple  
> implementations; the implementations that are in the core are not  
> intended to be the be-all and end-all of TinyOS code. The TEPs have  
> (for the most part) been carefully written with this in mind.
>
> Phil