Closed alonisser closed 8 years ago
Since we need all coding hands on board for other issues, and we do have content volunteers, I think we can do this work manually. :) On Feb 20, 2016 11:59 PM, "Alonisser" notifications@github.com wrote:
related to bug #513 https://github.com/hasadna/Open-Knesset/issues/513 but different cause and solution see for example vote 9434 https://oknesset.org/vote/9434/
- expected output: no "voted against opposition" in coalition members
- actual output: 2 coalition members are flagged with "voted against opposition"
The actual cause is that Mk that were also in the previous knesset and previous membership had not been closed (no end date) when moving to new knesset breaks the algorithm calculating wether the member should be counted as coalition or opposition in current knesset.
@morchickit https://github.com/morchickit I would fix the algorithm to close this issue, but not closed membership period might bite us in more places. Should we script something to close all non closed memberships of previous knesset - really not a problem I think (or @OriHoch https://github.com/OriHoch maybe there is one?) or is there a reason to do this manually?
— Reply to this email directly or view it on GitHub https://github.com/hasadna/Open-Knesset/issues/555.
@morchickit I always vote for automation and is quite simple, and who knows if there would be content volunteers next time this has to be done. My only question is if there are any content reasons not do this automatically (such as special info or decisions needed to be taken), if not I'll automate..
As we find lately, not all members if Knesset end their terms in the same time - parties converge, MK are leaving, etc. So giving the same end date to all MK would not be the good solution and probably will create more bugs. I think we should go manually and give it a clean and validate each MK case with the Knesset website info (unless you can use the Knesset API for that, but I am not sure how far the data go there...) On Feb 21, 2016 10:40 AM, "Alonisser" notifications@github.com wrote:
@morchickit https://github.com/morchickit I always vote for automation and is quite simple, and who knows if there would be content volunteers next time this has to be done. My only question is if there are any content reasons not do this automatically (such as special info or decisions needed to be taken), if not I'll automate..
— Reply to this email directly or view it on GitHub https://github.com/hasadna/Open-Knesset/issues/555#issuecomment-186775595 .
to properly automate this we should have a members scraper that will update all members info, start/end times etc.. I believe this data exists in Knesset Dataservice
however, it's manageable manually as well, even though it's quite annoying..
I was thinking on the lines of:
if knesset has ended and member for party in knesset has no end_date
then member.end_date = knesset.end_date
sounds good enough for now to me.. Until we set a complete members scrapers that would handle updating etc.
The specific bug was because of a mistake in the "party_at" algorithm. which I fixed, so this is only affecting other places we display this data or are influenced by it . Not sure there are such places :)
On Sun, Feb 21, 2016 at 12:45 PM, Ori Hoch notifications@github.com wrote:
to properly automate this we should have a members scraper that will update all members info, start/end times etc.. I believe this data exists in Knesset Dataservice
however, it's manageable manually as well, even though it's quite annoying..
— Reply to this email directly or view it on GitHub https://github.com/hasadna/Open-Knesset/issues/555#issuecomment-186796127 .
setting member.end_date=knesset.end_date IMO definately should not be done, because it will simply be wrong data..
about party_at - it might be OK to test for this condition and use the knesset end date specifically in this case, but I'm not sure if that's better in any way - both cases will show wrong data, the question is which data is more wrong (or more right)..
Ok for not setting member.end_date by knesset.end_date
The solution in party_at is different , the algorithm is wrong , i'll fix and you'll see
On Sun, Feb 21, 2016 at 2:11 PM, Ori Hoch notifications@github.com wrote:
setting member.end_date=knesset.end_date IMO definately should not be done, because it will simply be wrong data..
about party_at - it might be OK to test for this condition and use the knesset end date specifically in this case, but I'm not sure if that's better in any way - both cases will show wrong data, the question is which data is more wrong (or more right)..
— Reply to this email directly or view it on GitHub https://github.com/hasadna/Open-Knesset/issues/555#issuecomment-186813456 .
tested on production, looks like the warning on the 2 members disappeared, so I assume it worked..
related to bug #513 but different cause and solution see for example vote 9434
The actual cause is that Mk that were also in the previous knesset and previous membership had not been closed (no end date) when moving to new knesset breaks the algorithm calculating wether the member should be counted as coalition or opposition in current knesset.
@morchickit I would fix the algorithm to close this issue, but not closed membership period might bite us in more places. Should we script something to close all non closed memberships of previous knesset - really not a problem I think (or @OriHoch maybe there is one?) or is there a reason to do this manually?