Hello Rick,
What you describe is true. But I’ve not experience anybody notice this in the several years
that I’ve been doing it.
At meetings, folks know if they are voters if they have a natty voting token, or failing that
they’ll go the to 802.11 webpages to discover their 802.11 voting status. I suspect they don’t
even know how to determine their 802.11 voting status from MyProject.
And, yes, you do identify a corner case in the logic. I don’t know if we’ve ever hit that case.
Of course, we regularly hit the case of someone who is an 802.11 potential voter at the start of a meeting
records no attendance in 802.11, but spends their time elsewhere. They usually complain vociferously
at the unwarranted loss of voting rights at the start of the next meeting “where did my 802.11 token go?”.
Best Regards,
Adrian P STEPHENS
Tel: +44 (1793) 404825 (office)
Tel: +44 (7920) 084 900 (mobile, UK)
Tel: +1 (408) 2397485 (mobile, USA)
----------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
From:
Rick Alfvin [mailto:ralfvin@verilan.com]
Sent: Thursday, March 28, 2013 2:32 PM
To: Stephens, Adrian P
Cc: Christina Boyce; STDS-802-SEC@LISTSERV.IEEE.ORG
Subject: Re: [802SEC] Interpretation of reciprocal credit "rule"
Adrian,
If I understand correctly, you elevate your potential voters to voter status prior to a plenary meeting. So if I was a potential voter in 802.11, did not attend the plenary
meeting and I looked online at My Project during the plenary meeting I would be incorrectly listed as a voter, when in fact I was not.
I think that knowingly uploading false voter status to MyProject prior to a plenary may cause some confusion among our membership. For example, there is the situation
where a potential voter in .15 goes to the plenary but does not attend any .15 meetings, but instead attends .18 or .19 (receiving unwarranted reciprocal credit in .15) or .11 meetings to work on gaining attendance in another group.
By definition, IMAT is incapable of accurately recording reciprocal attendance unless it is capable of monitoring real time changes in attendance status.
Best regards,
-Rick
Sent from my iPad
On Mar 28, 2013, at 8:38 AM, "Stephens, Adrian P" <Adrian.P.Stephens@INTEL.COM> wrote:
Hello Christina,
There is one small subtlety regarding reciprocal credit.
At a plenary meeting, a “potential voter” has a voting token and can vote, and can record reciprocal credit.
At an interim meeting, a “potential voter” doesn’t have a voting token and can’t vote, and can’t record reciprocal credit.
I manage this by uploading a different “voters list” to MyProject depending on whether we are about to encounter
a plenary or not. If so, all my potential voters get promoted to voter, just in case they show up. Before an interim
I upload a list that properly shows potential voters.
This could be parameterised somehow in the tool, either by embedding business logic about the difference
between a plenary and an interim, or by parameterising the reciprocal credit logic so that admins can turn the
“does a potential voter get a reciprocal credit” switch off and on.
Absent either, admins need to be aware of this wrinkle and respond accordingly.
Best Regards,
Adrian P STEPHENS
Tel: +44 (1793) 404825 (office)
Tel: +44 (7920) 084 900 (mobile, UK)Tel: +1 (408) 2397485 (mobile, USA)
----------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
From: owner-stds-802-sec@ieee.org [mailto:owner-stds-802-sec@ieee.org] On Behalf Of Christina Boyce
Sent: Thursday, March 28, 2013 12:07 PM
To: STDS-802-SEC@LISTSERV.IEEE.ORG
Subject: Re: [802SEC] Interpretation of reciprocal credit "rule"
From: <c.sahr@ieee.org>
Date: Thu, Jun 5, 2008 at 10:46 AM
Subject: Change in Attendance Tool Direction
To: tony@jeffree.co.uk, adam.healey@lsi.com, wael.diab@gmail.com,
Adrian.P.Stephens@intel.com, alfvin@ieee.org, petermurr@mac.com,
shellhammer@ieee.org, mklerer@qualcomm.com, vivek.g.gupta@intel.com,
gerald.chouinard@crc.ca
Cc: paul.nikolich@att.net, gilb@ieee.org,
wpiencia@thunderdome.ieee.org, r.labelle@ieee.org, M.Kipness@ieee.org,
K.Cush@ieee.org, moeller@bivio.biz, tom@azgaard.com
All Attendance Tool Managers:
During the last few wireless meetings, it has come to my attention that the
Attendance Tool is being used by the Working Groups differently. I
understand that this has occurred because the tool does not
- provide a mechanism to calculate Letter Ballot results which is required
to calculate voting rights within your group and
- provide a method to integrate with the meeting registration system which
provides accurate voting rights on the meeting badges.
- accurately calculate voting rights within certain a working groups
With this in mind, I have met with the Attendance Tool developers, IEEE-SA
Management, and 802 Executives (Paul Nikolich and James Gilb) to discuss
options on how to move forward with the development of the Attendance Tool.
Our goal is to ensure it fits the needs of the 802 Working Groups as well
as other
IEEE-SA Standards Development groups, and to simplify the tool processes.
Here is how we are going to proceed:
* The Attendance Tool will continue to be developed as a meeting attendance
tracking tool. We will not be using it to calculate WG voting rights or
working group membership.
Many of you already have a tool that calculates the voting rights based on
the letter ballot results and there is no need to reinvent what you already
have.
* myProject will be enhanced so you can upload your WG voting rights
directly into myProject. So once you have your calculated voting rights,
you will upload them into myProject.
Since myProject is the primary source of user and project data, we want to
continue to keep the data in myProject. Looking down the road, this will
afford us to the possibility of creating a letter ballot system if needed.
The Attendance Tool will then use the voting right from myProject as the
source data.
* We will create a user account in myProject for the meeting planner to
access up to date voting rights data for badge printing.
When the effort is complete, the process flow will look like this:
1) Prior to the meeting start: Enter meetings in Attendance Tool Manager
2) During the meeting: Attendees log their meeting attendance
3) After the meeting: Chair will (bulk) download the attendance data form
the manager tool and calculate voting rights using letter ballot or other
algorithm
4) After the meeting: Chair will go into myProject and (bulk) upload the up
to date voting rights for his working group.
As you can see, steps one and two do not change, and for most chairs, step
3
does not change either.
We are hoping to make these changes in the next 30 days. I will keep you
up to date on the progress of this effort.
Christina Sahr
Technical Project Manager, IEEE Standards
445 Hoes Lane
Piscataway, NJ 08855
c.sahr@ieee.org
Phone732-562-5540
IEEE.. . Fostering technological innovation and excellence for the benefit
of humanity.On Thu, Mar 28, 2013 at 6:03 AM, Stephens, Adrian P <Adrian.P.Stephens@intel.com> wrote:
Hello Pat,
The current system allows attendance credit to be granted to selected group, provided they use IMAT
to record their attendance, and you as the IMAT
admin for your group can select those groups (on the granularity of WG/TAG/ECSG).
Let me summarise the current rules:
1. Those who attend a meeting (a visted group)
a. where they are a voter in another group (the home group)
b. and the home group has granted reciprocal rights to the visited group
2. if > 1 home groups, are presented a list of home groups and select one
3. Are awarded attendance credit in the visited group and the (selected) home group
The system doesn’t have the notion of “my real home group”.
Bruce is awarded voting rights in 802.11, 802.19, 802.18 by virtue of his chairfulness.
When attending 802.11 (his real home group), the system cannot tell that he is not
an interloper from 802.18, and forces him to choose between .18/.19 as his home group and silently awards
him 802.11 attendance as a “visited” group.
It seems odd that Bruce should be forced into getting .18/.19 attendance credit for attending his
own meetings.
The reciprocal rules apply only to voters.
When Bruce has wanted different rules, we have shown other meetings from time to time on the
802.11 IMAT so that non-voters could get credit for attending.
Best Regards,
Adrian P STEPHENS
Tel: +44 (1793) 404825 (office)
Tel: +44 (7920) 084 900 (mobile, UK)
Tel: +1 (408) 2397485 (mobile, USA)
----------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
-----Original Message-----
From: owner-stds-802-sec@ieee.org [mailto:owner-stds-802-sec@ieee.org] On Behalf Of Pat Thaler
Sent: Thursday, March 28, 2013 1:20 AM
To: James P. K. Gilb; STDS-802-SEC@LISTSERV.IEEE.ORG
Subject: Re: [802SEC] Interpretation of reciprocal credit "rule"
James,
I agree that a WG Chair should be able to opt their group in or out for reciprocal credit based on whether the Chair considers attendance at the other group to be for the benefit of the home group. For IMAT to track the credit, there should be a consistent rule on how credit works when one opts in. I think that could be in the Chair's guideline since 7.2.1 already covers the overall rule - that the WG Chair can choose to grant credit for contributions other than attendance at the WG.
Mentor will not cover all such discretionary credit. As a WG chair, I on occasion granted credit for attendance at one of the EC meetings during the week (e.g. the then equivalent to our meetings during the week on things like international standardization, IEEE 802 revision) and since then I've been granted credit in 802.3 or 802.1 for attending that type of meeting. But we should be able to come up with something consistent for covering WG-WG or WG-TAG credit.
Regards,
Pat
-----Original Message-----
From: ***** IEEE 802 Executive Committee List ***** [mailto:STDS-802-SEC@ieee.org] On Behalf Of James P. K. Gilb
Sent: Monday, March 25, 2013 2:40 PM
To: STDS-802-SEC@LISTSERV.IEEE.ORG
Subject: Re: [802SEC] Interpretation of reciprocal credit "rule"
Rick
I fully agree with you that we should have a single method for this. As I said "Still, it would be best if we had one algorithm all WGs agreed to with a simple opt in/opt out."
So, does that mean a WG P&P change? Chair's guideline change? Let us first agree what we mean (and all interpretations) and then see if we can get IMAT to reflect it.
IMHO.
James Gilb
On 03/25/2013 02:09 PM, Rick Alfvin wrote:
> Hi James, If each working group is allowed to define a different rule
> set for managing reciprocal credit we have a wee bit of a problem with
> the static IMAT attendance system that has a single method for
> assigning reciprocal credit. This problem is only compounded and
> exacerbated by the attendance system's inability to deal with or
> recognize real times changes in MyProject voter status occurring
> during plenary sessions, which in turn inhibits IMAT's ability to
> correctly assign reciprocal credit to a new voter.
>
> These two inconsistencies make it very difficult to determine
> attendance status and make the IMAT attendance system less than
> useful.
>
> Thanks, -Rick
>
> Rick Alfvin VP Business Development
>
> Verilan, Inc. 7327 SW Barnes Rd. #215 Portland, OR 97225
>
> Mobile: +1 (585) 781-0952 Email: ralfvin@verilan.com Skype:
> ralfvin.verilan Website: www.verilan.com
>
>
>
>
>
> On Mar 25, 2013, at 3:38 PM, James P. K. Gilb <gilb@ieee.org> wrote:
>
>> All
>>
>> I sent a much longer email, but as for the history, I believe Ivan
>> and I are in agreement. The WG/TAG chairs define what is reciprocal
>> rights for their group.
>>
>> For example, 802.24 TAG does not offer reciprocal rights to other
>> groups (i.e., that you could use 3 802.15 meetings to count as 100%
>> attendance in 802.24). I am pleased that some other WGs do offer
>> reciprocal attendance in their groups for attending 802.24 meetings,
>> but, AFAIK, it is their choice how to do it.
>>
>> Still, it would be best if we had one algorithm all WGs agreed to
>> with a simple opt in/opt out.
>>
>> IMHO.
>>
>> James Gilb
>>
>> On 03/25/2013 06:16 AM, Ivan Reede wrote:
>>> Well, if it can be of some use, I can give some history here, as I
>>> was around when the recoprocal rights were created.
>>>
>>> A long time ago, some TAGs had attendance problems because people
>>> would not attend them in fear of losing their voting rights in their
>>> WG. To alleviate this and allow the interested people to atend the
>>> TAGs and not lose thier voting rights in their WG, reciprocal
>>> attendance credit was created. This allows a user to attend a TAG
>>> and log their attendance in their WG, such as to be able to
>>> participate in a TAG and maintain thier voting rights in their WG.
>>> Chairs determine the TAG pertinence to the their WG by deciding to
>>> allow for reciprocal attendance credits between said TAG and their
>>> WG. Now thats it for the historical reasons for the reciprocal
>>> attendance credits. After that, TAGS were eliminated and called
>>> working groups... so now, chairs can create reciprocal rights
>>> between and WGs.
>>>
>>> In my opinion, "a" is the correct answer right now, although "b"
>>> is an interesting alternative which would greatly simplfy things,
>>> i.e. once you have acquired votingrights in one group, visiting
>>> another group with recpropcal voting rights would allow you to
>>> maintain your voting rights in the first group and would eliminate
>>> the "home group juggling" from one meeting to the next.
>>> It would not change things in the manner of what can be done, it
>>> would just simplify things by automating them rather than requiring
>>> the particiapnt to keep a record, session by session, of where to
>>> direct their reciprocal attendance and would simplify the software
>>> by removing confusing/cryptic questions. In any case, if one wants
>>> to mainting their voting rights in their home WG, they should
>>> concentrate their presence into a single WG during the entire week,
>>> thereby, the question asked at every single 2 hour period is
>>> annoying at best, outright confusing to newbies trying to use the
>>> attednance syste!
>> m. I think if "a" is maintained as the right choice, something could
>> be done to ask the "home group" question once for the entire week,
>> and leave it at that.
>>>
>>> Just my 2 cents worth, Ivan Reede, vice chair, 802.19 ----- Original
>>> Message ----- From: Jon Rosdahl To: Stephens, Adrian P ;
>>> STDS-802-SEC@LISTSERV.IEEE.ORG Sent: Saturday, March 23, 2013
>>> 12:57 AM Subject: Re: [802SEC] Interpretation of reciprocal credit
>>> "rule"
>>>
>>>
>>> a) I believe the current operation is correct (i.e., visited
>>> + 1 home)
>>>
>>>
>>>
>>> I think that the tool needs to be fixed in that the prompt is less
>>> than informative, and the instructions less than clear.
>>>
>>> I will work to get a ticket in place, to fix it up, but our input to
>>> help with the final expected operation would be helpful.
>>>
>>>
>>>
>>> I think that only a "voter" can make use of the reciprocal credit
>>> option, and it cannot be used to "gain" voting rights, but only to
>>> maintain them.
>>>
>>> When Marking Attendance, a choice of which "home" group should be
>>> selectable, and if you are attending your home group, and you only
>>> want home credit, that should be an option (currently it is not).
>>>
>>> FWIW,
>>>
>>> Jon
>>>
>>> ----- Original Message ----- From: Stephens, Adrian P To:
>>> STDS-802-SEC@LISTSERV.IEEE..ORG Sent: Friday, March 22, 2013 4:09 PM
>>> Subject: [802SEC] Interpretation of reciprocal credit "rule"
>>>
>>>
>>> Dear 802 EC,
>>>
>>>
>>>
>>> As mentioned at the EC meeting today, there is a question of
>>> interpretation regarding reciprocal credit.
>>>
>>> Although the answer may be buried somewhere in an EC motion or an
>>> IEEE-SA staff document before my
>>>
>>> time, I cannot find anything in the rules/OM relating to this.
>>>
>>>
>>>
>>> Definitions:
>>>
>>> home group - a group in which a user has voting rights
>>>
>>> visited group - a group that a user attends, which is granted
>>> reciprocal credit by the home group
>>>
>>>
>>>
>>> A voter visits a group and records attendance. The question is
>>> simple.
>>>
>>> Should the voter get attendance at:
>>>
>>> a) One of the home group and the visited group
>>>
>>> b) Both of the home group and the visited group (current)
>>>
>>>
>>>
>>> And if the voter has multiple home groups should the voter get
>>> attendance credit:
>>>
>>> a) One of the home group and visited groups
>>>
>>> b) The visited group and one of the home groups (current)
>>>
>>> c) The visited group and all of the home groups
>>>
>>>
>>>
>>> Current behaviour (modulo a few UI infelicities) is highlighted.
>>>
>>> I initially took this to be a bug, because I laboured under the
>>> mistaken assumption that
>>>
>>> attendance credit should not multiply unnecessarily. (Stephens'
>>> razor).
>>>
>>>
>>>
>>>
>>>
>>> I'd like to get feedback on how you think the system should behave.
>>> Once I get this, I'll
>>>
>>> document this behaviour, and if necessary work with Jon to raise a
>>> ticket to change it.
>>>
>>>
>>>
>>>
>>>
>>> Just to help provide rapid feedback, I have some stock responses
>>> prepared below:
>>>
>>> a) I believe the current operation is correct (i.e., visited
>>> + 1 home)
>>>
>>> b) I believe single attendance credit is correct (i.e.,
>>> visited or home)
>>>
>>> c) I don't do reciprocal credit, I have no opinion
>>>
>>> d) I don't care, I have no opinion
>>>
>>>
>>>
>>>
>>>
>>> Best Regards,
>>>
>>>
>>>
>>> Adrian P STEPHENS
>>>
>>> Tel: +44 (1793) 404 825
>>>
>>> Tel: +44 (7920) 084 900
>>>
>>> Tel: +1 (408) 239 7485
>>>
>>>
>>>
>>> ---------------------------------------------- Intel Corporation
>>> (UK) Limited Registered No. 1134945 (England) Registered Office:
>>> Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47
>>>
>>>
>>>
>>> ---------- This email is sent from the 802 Executive Committee email
>>> reflector. This list is maintained by Listserv.
>>> !DSPAM:514d2e5138661446669480! ---------- This email is sent from
>>> the 802 Executive Committee email reflector. This list is maintained
>>> by Listserv.
>>>
>>> ---------- This email is sent from the 802 Executive Committee email
>>> reflector. This list is maintained by Listserv.
>>>
>>
>> ---------- This email is sent from the 802 Executive Committee email
>> reflector. This list is maintained by Listserv.
>
>
----------
This email is sent from the 802 Executive Committee email reflector. This list is maintained by Listserv.
----------
This email is sent from the 802 Executive Committee email reflector. This list is maintained by Listserv.
---------- This email is sent from the 802 Executive Committee email reflector. This list is maintained by Listserv.
--
Christina Boyce, PMPManager, Standards Solutions Services
IEEE Standards Association
445 Hoes Lane
Piscataway, NJ 08854
Phone +1 732 562 5540
Mobile +1 908 239 4038
---------- This email is sent from the 802 Executive Committee email reflector. This list is maintained by Listserv.
---------- This email is sent from the 802 Executive Committee email reflector. This list is maintained by Listserv.