Text 10, 70 rader
Skriven 2005-07-08 17:49:07 av Thom LaCosta (1:261/1352.0)
      Kommentar till text 9 av Peter Knapper (3:772/1.0)
Ärende: Policy Update/Modification
==================================
Peter Knapper wrote in a message to Thom LaCosta:

 PK> Hi Thom,

 TL> Just wondering if it makes any sense to begin informal 
 TL> discussions of how the RCs might act if and when there 
 TL> is another proposed update to Policy?

 PK> I guess it all comes down to how much attention the proposed change
 PK> is able to attract. Based on the previous response, I tend to think
 PK> that GOOD RC communciation is probably the only way things might
 PK> start to move. I doubt that sufficient RC's monitor this or any
 PK> other Echo to guarantee enough coverage, so I have another devious
 PK> plot for this.........;-).

You're probably correct in the assumption that sufficient RCs don't montitor
this echo.....I think one thing we can do is attempt to gain their
participation before a proposal surfaces.


 TL> If a member of my 13 submits a proposed change, should 
 TL> I netmail it to the other RCs, announce it here or in 
 TL> another echo, or some combination of all these?

 PK> My own thoughts suggest that the main failure of combined RC
 PK> reaction from last time was possibly caused by the major issue of
 PK> comunication, and by that I simply mean the language barrier. 

Likely a correct assumption.

 PK> So... one possible method might be -
 PK>   1. A complete NEW version of Policy is prepared by those
 PK> requesting a change.   2. Once agreed, that NEW document is then
 PK> sent to an RC who is willing to run with the proposal and act as
 PK> the RC "contact point". The document is LOCKED at that point to
 PK> avoid confusion.

That makes sense....but that group of submitters might be urged NOT to shop the
proposal around, else multiple RCs might attempt to move it forward.


 PK>   3. The nominated RC then sends the document TO EACH ZC, along
 PK> with a request that the ZC's put it to each ZC's group of RC's,
 PK> along with a Target RC Vote Date that the documet be put to the
 PK> *C's for the final vote. This puts the communication issue in the
 PK> place that has the BEST chance of reaching the RC's, the ZC's
 PK> normally receive Nodelist segments from their RC's anyway, so
 PK> communication paths are likely to be in place for most of them.  
 PK> 4. The result from step 3 is that the document either goes forward,
 PK> or it does not.

The downside of that aprroach, as we saw the last time around, is that one ZC
might either choose to ignore or influence the action of his/her RCs.

 TL> Persoanlly, I think the RCs need to discuss how we 
 TL> might operate, rather than have someone else tell us 
 TL> how we should....and, as far as I know, there isn't a 
 TL> formalized procedure.

 PK> Well the above could be a start...........;-)

Perhaps another alternative would be to find at least one RC in each zone who
would be willing to act in the manner you've suggested for the ZC to act.  In
that way, the effort is one of the RCs...not any outside forces.

cya,
thom
http://www.tlchost.net/echolist/ 
--- GEcho 1.20/Pro
 * Origin: Home of The Other Robot (1:261/1352)