As mainnet has evolved it appears that paying workers with the fluctuating exchange rate has become a bit annoying. WG leads must time their payments and do some annoying calculations to make sure things line up properly. It is likely the impact of this will be somewhat lessened when we move to the new one month council duration but it is still a "papercut" that adds a certain amount of friction to the WG leads workflow.
I think the theory with the current system was that workers would have a relatively stable payment that would only change periodically. It is really difficult to anticipate how much the price of the token may fluctuate in the future. In the event of dramatic price fluctuations it is possible in the current system for workers to be vastly overpaid (although this is somewhat mitigated by the current usage of the EMA30 pricing metric)
Leads must currently rely on the CLI which is not very straightforward to use and given the requirement for various manual calculations is prone to human error. This reliance on the CLI is not a great long term strategy as it limits the pool of candidates for WG lead positions to only people with very high technical skills.
Socially, WG budgets are done in coordination with the council only once per term, which means there are few circumstances when a worker's salary is adjusted in the middle of a council term--although this may happen as a sanction against underperforming workers. The only other instance where something similar may happen is when a new worker is hired mid-term, but that doesn't involve the same difficulty.
The current payment interval is about 1 day, which means after the start of a council term it takes about 2-3 days for budgets to be agreed upon. To also factor into this, there are sometimes weekends and public holidays that delay things. This means it is annoying for a lead currently to try and perfectly time worker payment adjustments.
Some leads are doing partial payouts to workers via the spendFromBudget (discretionary spending) extrinsic in order to deal with this. This causes a great deal of annoyance because unlike the rewardPaid event that is tied to a worker ID, the spendFromBudget extrinsic is not tied to a worker ID
Solution 1 - manual push payments to workers
Allow the lead to toggle workers between auto payments and a manual push payment type that they can do once per term
or remove automated payment events entirely and change to a completely manual push payment system
Add a workerId field to discretionary payment extrinsic or add a new extrinsic entirely that triggers a rewardPaid event
Solution 3 - reduce the payment interval
It seems extremely unlikely that we will ever move to something less than a 1 week council period duration. The current worker salary payment interval is only ~24 hours which makes timing of things really difficult. If the timing were something like once per week it would allow a lot more time at the beginning of a council term to adjust things.
This adds some complexity of aligning with the duration of the council term (especially if an election fails or something like that)
Solution 4 - Heaving invest in a worker salary tool within Pioneer
It seems like this may be quite a strong option. If this tool were simple enough to use, and could account for how much a worker has already been paid in the current council term and then adjust the rest of the rewards it could work quite well. If done properly it may just become completely trivial enough for a lead to put in a few numbers and adjust the payments to a worker once per term.
Solution 5 - Greatly improve the CLI
I am not personally a fan of this one and I think the resources would be better spent on implementing worker reward adjustments within Pioneer itself as there are a lot more long term benefits.
Problem
As mainnet has evolved it appears that paying workers with the fluctuating exchange rate has become a bit annoying. WG leads must time their payments and do some annoying calculations to make sure things line up properly. It is likely the impact of this will be somewhat lessened when we move to the new one month council duration but it is still a "papercut" that adds a certain amount of friction to the WG leads workflow.
spendFromBudget(discretionary spending) extrinsic in order to deal with this. This causes a great deal of annoyance because unlike therewardPaidevent that is tied to a worker ID, thespendFromBudgetextrinsic is not tied to a worker IDSolution 1 - manual push payments to workers
Solution 2 - adjust discretionary spending extrinsic
workerIdfield to discretionary payment extrinsic or add a new extrinsic entirely that triggers arewardPaideventSolution 3 - reduce the payment interval
Solution 4 - Heaving invest in a worker salary tool within Pioneer
Solution 5 - Greatly improve the CLI