The current vote has a link to a draft RPIP. There is currently a PR for reviewing that draft, tweaking and finalizing, but that didn’t happen prior to the vote going live. That PR had quite modest tweaks (see image below with Draft on the left and PR changes on the right).
My leaning is to move forward with the PR text, since (a) that reflected the best state the author had available, (b) the changes are quite small, (c) this is a landslide vote at this time, and (d) it is equally easy to vote for a change as to redo the vote.
I’ll explain the changes here. FYI these were in Github well before the snapshot started but it was a combo of the editors not finalizing and me forgetting to remind them to finalize which is why it got lost.
This might be X RPL paid over 12 months.
The use of ‘might’ in this example simply gives an example or idea of how the payments will be made. When the payments from the GMC commenced, it became apparent that a monthly payment schedule was far more feasible than thirteen inflation cycles. This explanation doesn’t alter any actual arrangements, but rather provides a more precise understanding of the process.
–
Assign individual committee members for verification, if work is specialized
This ensures that due diligence is employed when the scope of the work exceeds the administrator’s expertise.
–
Any GMC member who submits a bounty SHALL not complete that bounty.
Joe requested this so he can’t start getting double paid for all his work.
–
The job posting will be accessible to the public, allowing interested candidates to submit their applications within a designated 14-day window.
The application window was doubled to give more time for interested applicants.
–
For what it’s worth, using the original Draft text wouldn’t result in a significant “loss” since I provided applicants with more time by posting the details early, and the bounty claim is merely a formality. Nevertheless, I believe redoing the entire vote would be highly inefficient.
Generally speaking, I would be in favor of redoing the vote despite the delay due to the governance process. This is another situation where Governance Legitimacy gets undermined if the rules aren’t followed and there aren’t any consequences for it. At Maker, our exceptions and “reasonable” bending of the rules always came back to create a bigger problem later.
In this situation you can imagine how it might be harder to enforce a “deadline” rule in the future as a community member could point to a time when a technical exception was made.
There’s also some minor worry about the voters; did they vote on this proposal expecting the draft version or the published one? Anytime you are put in the position of trying to guess what a multitude of parties understood at the time of voting, it’s generally best to just let them clarify it with a separate vote.
With all that said, I am sympathetic to the situation and it sounds like from the following this could just be a time where a clear and legitimate exception is made, and a new process or procedure is put forward to prevent this happening again.
Posting about this publicly and holding a poll are a great way to minimize the legitimacy loss, and, especially with social layer procedures, there is some expectation that things will need to be refined once exposed to the “real world.” I appreciate this post and look forward to hearing more active participant’s take on the matter.
I voted to redo, but only because it was the least bad option that looks to have a chance of prevailing. Even though this seems minor, I agree with prose we should be very cognizant of the precedent, and I think approving a version that was not merged, and not linked to the vote is a bad idea. I think we should have confidence that the thing we (hopefully) read when submitting the vote, is the thing we’re actually agreeing to. I won’t lose sleep over it, but we should endeavor to following procedures as written this time, so we can do it every time.
In the case where “If vote passes, it approves the draft text” starts to lead, I’ll switch.
ETA: Question, is the vote even “legal” if the RPIP is in draft mode, or is final required? Don’t know off the top of my head.
Promising community sentiment and a corresponding RPIP document (successfully past the Review stage) are REQUIRED for snapshot voting to be scheduled.
So the process was definitely not followed. The question is what do we do. Do we another vote and delay 3ish weeks, or count the vote. If the vote was at all close, it would be an obvious redo. If the different texts varied a lot, I think that would also be a clear reason to redo to me.
This is actually my other concern… Nobody noticed that it was a draft
I just sat down to catch up here and do this vote, but I’m not sure I would have seen the draft status. Will always look from here on.
I know vote fatigue is a worry, and yeah this should get in. I’d still prefer if the draft were adopted, and anything that really needs it, can get a revote, but honestly the things that were in the PR mostly look like they could be implemented inside the GMC via process. Again though, I won’t lose sleep if the PR version is what stands. When I vote I’ll somehow vote for both versions in my head.
Adding this statement so I can point back if I need to. I do not see this as precedent that we can / should do this whenever there’s an issue like this. Hopefully we’ll catch things like this early on in the future.
Although I view the edits as minor and non-substantive, I think the legitimacy of the vote matters. I think we should perform a second vote to validate the edits before enacting them as minor as they may be.
Perhaps they can be added as a trailer bill to the next vote if we are worried about voter fatigue.
Joe (a committee member, and team member) has submitted upwards of several bounties a month. He saw a loophole where he could be claiming bounties while getting paid by the team and wanted this line added to close it.
Yes, I believe I understood the context. The reason for the proposed change can be fairly trivial (closing a perceived loophole), but the actual change can still be non-trivial.
Like, compare to the 7 to 14 day window change. Okay, a time limit has increased, but there’s no real impactful change there, it’s just an extension of the window to make it more likely to be seen by potential candidates.
Compare to the RPL schedule change. Schedule change clarifies an explanation but doesn’t alter arrangements, no problem, I would feel comfortable making that change without a vote if I were in the editor role.
I think in my mind, there is a difference in kind between those two changes (essentially UX changes), and the logical change preventing GMC members from claiming their own bounties. Following on from that, the presence of a difference in logic between the text-as-seen-by-voters and the text-that-would-be-marked-approved is what puts me in the ‘redo’ or ‘approve draft text’ camp.
(I’m aware to most people this probably seems like an entirely trivial and pedantic matter, and my POV on it even more so. But eh, everyone was referring to all the changes as minor and non-substantive, and like, that one isn’t non-substantive, it defines a rule which would be enforced as if the pDAO had voted for it, when they haven’t.)
