rchain / bounties

RChain Bounty Program
MIT License
90 stars 62 forks source link

disallow votes on issues created after the current pay period #682

Closed dckc closed 6 years ago

dckc commented 6 years ago

653 was created May 2, but some budget and rewards are scheduled to apply in the April pay period, since votes thru May 8 apply to the April pay period. I suspect it was a mistake. In any case, it's causing problems for the participants to work out the budget and rewards together.

Let's tweak the app to prevent this unfortunate case from happening again.

I'm inclined to apply this retroactively, but reviewing the affected issues shows some where the work was clearly done in April...

select issue_num, title from (
  select distinct issue_num from budget_vote
  where issue_num >= 644 and pay_period < '2018-05-01'
  union all
  select distinct issue_num from reward_vote
  where issue_num >= 644 and pay_period < '2018-05-01'
) oops join issue on issue.num = oops.issue_num;

Benefit to RChain Membership:

Clarify budget and reward negotiations and make sure there is plenty of time.

suggested budget: $300 (including coordinating with those affected)

cc @kitblake @lapin7

Valentine-Mario commented 6 years ago

I had the same conflict sometime ago. It would be good if it is verified so that in future times, issues created for a particular month only get reward for that month.

dckc commented 6 years ago

An idea from a brainstorming session today with @barneycinnamon , @ICA3DaR5 , @allancto was to use trust metric weight to decide which votes to postpone for review. So for each of the 10 issues in question, the weight of the reward voters along with the currently scheduled reward follows. In a separate comment, I'll make a suggestion based on these data:

pay_period issue_num reward_usd voters weight
2018-04-01 #648 1750 ottermagically:m*7, PatrickM727:, pmoorman:m*7 14
2018-04-01 #649 0 Cryptovideos:j*3, lapin7:m*7 10
2018-04-01 #653 3000 Pionelle:, Valentine-Mario:, BelovedAquila: 0
2018-04-01 #657 3430 AbnerZheng:j*3, notbdu?, dckc:m*7, MParlikar:m*7 17
2018-04-01 #661 1100 kaka56:, BelovedAquila:, dckc:m*7 7
2018-04-01 #662 1986 Valentine-Mario:, Ojimadu:a*1, David405:, Preshcode:, Keaycee: 1
2018-04-01 #663 695 Pionelle:, Kencode7:, ResonanceXX:, lapin7:m*7, Valentine-Mario: 7
2018-04-01 #664 85 Pionelle:, ResonanceXX:, Valentine-Mario: 0
2018-04-01 #667 0 Viraculous: 0
2018-04-01 #668 250 Viraculous:, BelovedAquila:, Ojimadu:a*1 1

Query

select iv.pay_period
     , concat('#', iv.issue_num) issue_num
     , coalesce(rtot.reward_usd, 0) reward_usd
     , tv.voters, tv.weight
from (
  select distinct pay_period, issue_num from (
    select pay_period, issue_num from budget_vote
    where issue_num >= 644 and pay_period < '2018-05-01'
    union
    select pay_period, issue_num from reward_vote
    where issue_num >= 644 and pay_period < '2018-05-01'
  ) av
) iv
left join (
  select pay_period, issue_num, sum(reward_usd) reward_usd
  from reward
  group by pay_period, issue_num
) rtot on rtot.pay_period = iv.pay_period and rtot.issue_num = iv.issue_num
left join (
  select pay_period, issue_num
       , group_concat(sig separator ', ') voters
       , coalesce(sum(weight), 0) weight
  from (
    select distinct pay_period, issue_num, sig, weight
    from reward_vote rv
    left join user_flair uf on uf.login = rv.voter
  ) rvwt
  group by pay_period, issue_num
) tv on tv.pay_period = iv.pay_period and tv.issue_num = iv.issue_num

order by issue_num
;
dckc commented 6 years ago

I moved all but #648 and #657, which had >10 weight each.

drop trigger current_edit_bv_update;
drop trigger current_edit_rv_update;

update reward_vote set pay_period = '2018-05-01'
where pay_period = '2018-04-01'
and issue_num  in (
 -- #648 
  649 
, 653 
-- #657 
, 661 
, 662 
, 663 
, 664 
, 667 
, 668);

update budget_vote set pay_period = '2018-05-01'
where pay_period = '2018-04-01'
and issue_num  in (
 -- #648 
  649 
, 653 
-- #657 
, 661 
, 662 
, 663 
, 664 
, 667 
, 668);

Then I turned those two triggers back on (see https://github.com/dckc/rchain-dbr/blob/master/dbr_triggers.sql ).

barneycinnamon commented 6 years ago

@lapin7 When reviewing invoices, you can check to confirm that the people listed below didn't accidentally include in their April invoice rewards associated with the issues beside their usernames in the table here. I believe the query that generated these was based on issue votes, so it is possible some of these people voted on rewards for associated issues but didn't receive rewards themselves (no problem) and possible that some people received rewards for these affected issues but did not vote on them (problem).

Username Issues
Pionelle #653, #663, #664
Valentine-Mario #653, #662, #664
BelovedAquila #653, #661, #668
kaka56 #661
dckc #661
Ojimadu #662, #668
David405 #662
Preshcode #662
Keaycee #662
motionfactory-digital commented 6 years ago

@dckc Howzt Dan - sorry to worry you but does this mean i must not do #649? im still not up to speed on this technical stuff - apologies

dckc commented 6 years ago

No, it just means votes for #649 belong in the May pay period, not April.

motionfactory-digital commented 6 years ago

Tsk Dan all good!

lapin7 commented 6 years ago

653

661

662

663

664

668

Are not in April Pay Period, they have been moved to May Work Period

Valentine-Mario commented 6 years ago

@lapin7 does that mean #662 would be in April invoice?

lapin7 commented 6 years ago

@Valentine-Mario Yes they have been moved to May invoice.

dckc commented 6 years ago

Database triggers enforce this constraint now.

fixed in https://github.com/dckc/rchain-dbr/commit/cac617327ec747881593f36ff9d5368ff6aa4da9

barneycinnamon commented 6 years ago

@lapin7 @jimscarver @TrenchFloat One vote shy for budget and one vote shy for rewards. If any of the guides want to jump in and nudge it over, that would be nice.

kitblake commented 6 years ago

@barneycinnamon Done, this issue is now 'provisioned'.

That's a term the Marketing guides use, meaning the budget and rewards are not provisional anymore. So @lapin7 @jimscarver @TrenchFloat don't need to take action.