ml> On 2018 May 30 23:47:42, you wrote to All:
PK>> To date, we have received a total of 16 votes. Once Mr Riccio
PK>> verifies all votes, I will release a current status. ALl netmails have
PK>> been replied to with Mr Riccio CC'd for verification. I was hoping to
PK>> see more votes but we have time.
ml> were those replies sent direct or crash or were they sent routed??? direct
ml> would be the best for security...
They should have been direct crash but probably routed as I only had 1 eye open
this morning.
PK>> Please review the Election rules. 2 votes are under review as they
PK>> are not listed in the 4 May FidoNet nodelist. It could be that I
PK>> overlooked them but have double checked & pending verification.
PK>> As per the election rules established at the beginning of the
PK>> election process, this is the official nodelist to be used as
PK>> verification. Any vote received that is NOT in the 4 May official
PK>> weekly nodelist, not the daily, but the "official" nodelist, will not
PK>> be counted.
ml> that could be a problem... we know there's been a problem with the
ml> weekly nodelist dropping entries that are/were in the daily
ml> nodelist... i would suggest to use both to ensure that someone that
ml> is rightly and properly listed is counted and not skipped because of
ml> an error...
ml> )\/(ark
I fully understand what you are saying & am debating it. However, is it not the
RC's job to ensure the nodelist is accurate & current for thier Region, same as
for NCs? If they are unable to perform that function for a Region, how will
they perform at the Zone level?
But then again, I dont receive a daily nodelist, P4 doesnt recognize it as an
"official" nodelist, or even a nodelist at all. And the election rules clearly
states which nodelist to use. It is kinda late in the game to be discussing
technical issues about an unofficial nodelist.
But, it is in debate & being re-considered.
BTW: Can anyone explain why I received a netmail from the Z2C on this very
topic when this is a "Zone 1" election?
Phil
--- Msged/LNX 6.1.2
* Origin: Bayhaus.net - Colorado Springs - Serving the FrontRange (1:128/2)
|
