How do members who don't want this proposal to go through vote against it?
There is no way to vote against a proposal. You can however revoke a previously granted approval for a proposal with "active_approvals_to_remove".
The 'review_period_time - 2015-10-28T11:00:00' is too soon. (Now is "2015-10-28T03:39:48") I think we need more time for committee members to review and approve it. Perhaps give it about 5 days at least?
A proposal has an expiration time and a review period. No new approvals may be added during the review period, and a committee proposal must have "committee_proposal_review_period" seconds (with get_global_properties, you can see it is currently 3600 seconds, or one hour). A proposed parameter change will take effect at the next maintenance interval after the review period.
We learned through experience in testnets that it would be wise to launch with a short committee_proposal_review_period and centralized control of a quorum of committee members (i.e., putting all the init accounts in the committee) in order to allow us to react quickly when critical problems arise. (And we were later glad we did.)
And what's with old proposals being inaccessible? get_object(1.10.1 thru 1.10. all return "null".. I think there needs to be an easy way to reference previous changes..
Originally we designed to have Graphene consist of a core, which only tracks what's needed for validation, and plugins, which track any historical data users might be interested in (e.g. account transaction history, market price / volume / order history, chain budget history, old proposals, etc.) According to the original design, witnesses would only run core, users running local wallets would track account history (but only for their own accounts), wallet providers would track account history for their userbase, etc. You'd be able to change what you track just by reconfiguring your plugins and re-indexing.
That's the theory, but in practice, as the release date approached and we started to worry more about shipping and less about code purity:
- We've put some things in core that really ought to be in plugins
- Plugin configuration is a difficult, undocumented, compile-time process
- Writing plugins is a difficult, undocumented process, even for core developers
I have a ton of improvements in mind to move code to the place in the architecture it should properly go, and greatly simplify and document the process of creating plugins. Which should lead to a highly modular, configurable experience for any kind of chain state tracking you want to do. But I can tell you that it's not likely something I'll get to this week, or next week. Maybe not even next month.
For now, I can add proposal tracking to core.