On Mon, 20 Nov 2017, Alex Smith wrote:
> On Mon, 2017-11-20 at 09:48 -0800, Kerim Aydin wrote:
> > You can see how it would work better for hard-coded matters of
> > economic policy: "if elected, I'll double the supply of land/halve
> > the cost of pending proposals" or whatever (though if most of the
> > campaign proposals are like that, there was a lightweight version
> > called 'budgets' that we used to do).
>
> That sounds a lot like a Regulation to me. If we decided to make more
> use of them (and I'm still pretty iffy on the current implementation),
> we could perhaps have Campaign Regulations (which get promulgated
> automatically) rather than needing them to be Proposals.
>
> (For what it's worth, my preferred version of a Regulation would be a
> tracked statement that has no Power, but that can define values that
> rules are capable of inspecting.)
Regulations could work. The old system was sort-of like this:
A Budget is a document maintained by an Officer that contains
the values of certain switches defined as being part of that
Officer's Budget. The Budget is part of that Officer's Report.
The Officer maintaining that Budget CAN flip its switches
[subject to whatever per-item constraints] Without Objection.
[i.e. things can be adjusted at any time, but only with
full consensus]
A nominee SHOULD submit a Prototype Budget with legal values
for all the budget's switches. These are included in the
Election Decision initiation. When the winner is installed
in office, the switches are all flipped to the values in the
winner's Prototype. [no separate voting process needed]
In the current system, the Treasuror's Budget would include
Supply Level, Pend Cost, CFJ Cost, Officer Rewards, etc. instead
of them being hard-coded in Rules.
In a decentralized system, you split this among Officers, so
the Treasuror controls the Supply Level, the Arbitor the CFJ cost,
the Promotor the Pend cost, the ADoP the Officer salary, etc.,
all as part of their separate Budgets.
