I have published on GitHub here a mock-up of how I would love the team at Yours.org to publish the rules by which the fees and prices on the system are set and transacted. It uses pseudocode that is intended to be strictly unambiguous, making it suitable to be used as a reference for both the Yours.org team and its users, in case they decided to use it.
The top ~50 lines of pseudocode look a bit like this:
https://imgur.com/a/HLZ4L
I've had the idea while reading Yours.org's "About" page some time ago, as soon as I bumped into the first ambiguity caused by trying to express the rules in conversational English. I'm not English mother-tongue, but I've been living in London, UK, for many years, so I don't think it's me being dumb 😁 nor it's Yours.org team's fault: natural language is just weak at describing that kind of dynamics.
Publishing the rules using a public GitHub repository has a lot of advantages:
  • it would allow Yours.org to be absolutely transparent and unambiguous about the rules - particularly if pseudocode was developed further and made into actual code, integrated in their system's code;
  • it creates a space for a more open and systematic discussion of the rules than possible on Slack, e.g. by proposing changes using pull requests, discussing them in GitHub's "Issues" forum, etc.
  • it creates a historical record of what the rules were in the past.
I hope my work was useful, and look forward to Yours.org team's and your feedback.
Note that:
  • I am not associated to the team at Yours.org, however I have been advising them informally, through their Slack channel and in private sessions. My work was reverse-engineered from observing the public features of the website only, and reading its documentation, and is not built on any confidential information I got from the team.
  • Although this looks a lot like JavaScript, it is intended as pseudocode only. It can't be run as it is, and would not work. Among the many issues, the code should assure transactionality (e.g. it should not be possible to record multiple upvotes on the same article in parallel, but the code should rather strictly respect the chronological order of the upvoting events), and I use Array.prototype.includes() incorrectly, for the sake of expressivity. However, with a little extra work, the real thing may not look too different from this.
 

$8.68
0.0¢
Comments
  spent 10.0¢
I think that even better than having a psuedo-code publishing would be having an actual code/data publishing. Even a simple JSON block that contains all of the relevant parameters, would work fine. The data block could then be pulled in by YOURS software to configure itself.
0.0¢
   1yr ago
10.0¢ 1.0¢
  spent 10.0¢
@Blake that's the idea, it's described in my last bullet point.
0.0¢
   1yr ago
1.0¢
  spent 10.0¢
I've updated the code to mirror Clemens' announcement on the changes to the voting reward model. See here.
0.0¢
   1yr ago
9.8¢ 1.0¢
  spent 10.0¢
I've updated the code to mirror Clemens' announcement about the changes to the voting reward model. See here.
0.0¢
   1yr ago
1.0¢ 9.8¢