Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802SEC] Interpretation of reciprocal credit "rule"



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 syst!
 e!
> 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.