RE: [RPRWG] Voting for proposals
I agree with Pankaj and we should vote on issue by issue rather than on the
document as a whole.
-Kumar
-----Original Message-----
From: Pankaj K Jha [mailto:pkj@xxxxxxxxxxx]
Sent: Thursday, November 08, 2001 5:41 PM
To: Mike Takefman
Cc: Siamack Ayandeh; stds-802-17@xxxxxxxxxxxxxxxxxx
Subject: [RPRWG] Voting for proposals
Hi Mike:
I fully agree with your approach on focusing on technical issues and not
editorial ones. I feel eliminating
entire documents through voting until only two remain is not a smart idea.
Maybe other dot groups have been
doing it for a while, but it still doesn't make it a good idea.
What our technical editor should do is to start with an IEEE 802.x template
document. Then based on votes on
individual issues that are represented in different documents and take
issues (cut-and-paste them) from those
documents and thus complete a baseline. The authors have already used IEEE
templates, making it even easier
to do a cut-and-paste.
Every document has good and bad sections. Eliminating an entire document
because it didn't garner enough
hands at the voting would be a waste of so much work that had gone behind
creating the document. We've this
meeting and next meeting and all the time in between to do this editing, and
we can easily accomplish this.We
only have a handful of documents to look at, so it shouldn't be hard.
Then we would've taken the best of the work and have a document that
represents consensus work. From then we
can work further on the issues to complete a draft standard.
Best regards,
Pankaj
Mike Takefman wrote:
> Siamack,
>
> based on presentation slots requests I believe that there are
> three proposals before the WG.
>
> In terms of how to proceed forward with these documents. It is up
> to the WG to determine procedure. Most dot groups work on the
> method of eliminating proposals one by one. Once down to two
> proposals, they see how much support each proposal garners
> and go from there.
>
> At the end of the day, when there are two proposals where
> neither can garner the required support a compromise is
> found.
>
> I think it is important that the writers of all of these
> contributions get feedback as to how much support their
> documents have of WG members. There are any number of ways
> of doing this.
>
> We have November and then January to get to an intial draft.
> Ignoring the issues of technical debate / disagreement, I
> suspect any of these drafts can form a baseline to start from.
> People should be focusing on the technical comments and
> not the editorial ones. That is what we get editors to do.
>
> We can potentially get agreement on non-contenious issues and
> show significant progress. But at the end of the week, if we
> want to hit the January date the authors of the drafts need to
> learn from people what compromises are needed to reach a
> concensus position.
>
> My view is that people are not voting for the "standard" but
> for a baseline document. Then, committees can be formed to
> work through the technical details and resolve comments and
> flesh out more details and work with the claus editors.
> However, this document should spell out some of the major
> design decisions that the group wants to follow.
>
> The WG will eventually ballot the draft so there is always
> the opportunity for dissent.
>
> see you in Austin,
>
> mike
>
> Siamack Ayandeh wrote:
> >
> > Mike,
> >
> > I have a couple of questions. How many proposals will there be in front
of the working group? Is it two
> > or four or perhaps a different number? And what is the procedure and
purpose of reviewing these
> > documents. Is it to converge them somehow to one proposal before it
moves forward similar to the T&D
> > document.
> >
> > Siamack
> >
> > Mike Takefman wrote:
> >
> > > Dan,
> > >
> > > Obviously it is unfortunate that you, and people from EMEA
> > > are not able to review the material prior to the meeting.
> > >
> > > However, this is a democratic organization and you need
> > > to get a passing vote to change the proceedures.
> > > You are certainly free to make the motion again and I
> > > encourage another debate on the topic.
> > >
> > > With regard to voting at this meeting, I believe it is
> > > reasonable to delay voting until later in the week
> > > to allow people time to review the documents.
> > >
> > > cheers,
> > >
> > > mike
> > >
> > > > "Romascanu, Dan (Dan)" wrote:
> > > >
> > > > Hi Mike,
> > > >
> > > > Here came my Thursday evening, which is the last day in my working
week, and no presentation is
> > > > yet available on the Web site for the meeting next week. No material
from the different teams that
> > > > announced intentions to work on proposals from San Jose until now is
available, with the exception
> > > > of the T&D team documents. For me, and other people coming from my
area this means that we will
> > > > not see these materials before Monday morning - with the exception
of the presentations of the
> > > > people who did the 'wrong thing' and sent their presentations to the
whole list.
> > > >
> > > > I tried to make a motion in a previous meeting about presentations
being made available in advance
> > > > for review and examination. Unfortunately, the motion did not make
it. I will try to make a case
> > > > again for providing the material in advance:
> > > >
> > > > * There is no reason why a serious technical material cannot be
made available one week, or at
> > > > least three days in advance to a meeting - at least in a
preliminary form. (Does anybody
> > > > really believe that a material prepared at the last moment,
sometimes during the flight to a
> > > > meeting can be solid enough for a serious technical standards
work?)
> > > > * The current system puts an unfair handicap on individuals who
already made relatively higher
> > > > efforts in traveling from remote locations to attend the IEEE
meetings
> > > >
> > > > The situation seems to me even more serious before this meeting,
when we will be required to vote
> > > > on some important decisions.
> > > >
> > > > Regards,
> > > >
> > > > Dan
> > > >
> > > >
> > >
> > > --
> > > Michael Takefman tak@xxxxxxxxx
> > > Manager of Engineering, Cisco Systems
> > > Chair IEEE 802.17 Stds WG
> > > 2000 Innovation Dr, Ottawa, Canada, K2K 3E8
> > > voice: 613-271-3399 fax: 613-271-4867
>
> --
> Michael Takefman tak@xxxxxxxxx
> Manager of Engineering, Cisco Systems
> Chair IEEE 802.17 Stds WG
> 2000 Innovation Dr, Ottawa, Canada, K2K 3E8
> voice: 613-271-3399 fax: 613-271-4867