here's some ideas I had for structuring the program. Feel free to add your own/organize.
Basically, first someone enters the meeting rules into a config file, which I call a RuleFile. Then they run a compiler on the RuleFile. The compiler turns the rules into a Python module. Each motion is its own class, subclassed off of a class Motion.
By allowing Python code in the rules, we allow people to arbitrarily extend the system. By creating our own config file syntax, we allow people who aren't programmers to understand most of the rule definitions (see the current version of the default RuleFile).
There will be a default, precompiled RuleFile included with the distribution.
When the user runs the program, there is a State, i.e. the current state of the meeting, including the stack of current motions, etc. At any given state there is a set of valid state transitions, which are mostly the allowable motions. One applies a state transition to the state to get a new state (i.e. this is how you would make a motion).
In order to determine which motions are valid at a particular time, you instantiate the motion that you want with the current state, and call a method that asks it, "are you valid?".
In order to apply a motion to the current state, you call State.apply(Motion), which in turn mainly just calls Motion.applyTo(state).
The UI is built on top of and separate from this underlying logic. We could have an ncurses UI and a GUI, etc. We could even incorporate the underlying logic into web-based meeting systems.
---- === Rough notes ===
core functions:
each motion (each state transition) is a Python object. key methods:
but there's also other methods (less general) like:
(i.e., given the current state, is this motion debatable?)
(actionAllowedOn is an intermediate level of generality; its not as specific to any one set of meeting rules, but not as general as the state transition stuff at the top)
(should this really be in the same Python object? sure, why not. should these be the same objects as the ones put on the motion stack to represent each motion? sure, why not) (perhaps two levels of API; this stuff is in the more specific API)
state object has methods, like to navigate the motion stack
note that most minor methods, like isDebatable, should take "state" as an argument even if you don't think its needed, for extensibility (i.e. to allow people to make up other sets of meeting rules that are arbitrarily context-dependent).
----- == UiIdeas? ==
three panes.
Left pane has misc stuff (e.g. "back" and "forward" buttons, like in web browsers)
middle pane has available/valid actions (i.e. state transitions; motions and other things). a small text field at the bottom allows you to type in ANY action, valid or not, and apply it to the current state. it has an autocomplete feature (it's like an address bar). One click to select a motion, two to apply it? I envision that the motions will not appear as "buttons" in the usual sense, but in a stack of fat rectangles with no intervening space (that you can click on).
right pane has information on the current state; the motion stack (tree?), and, perhaps, below it, in the last quarter (third?) of the page, information about the currently selected motion, or maybe a relevant excerpt from RRO. or general status info for the current state (i.e. "what are we supposed to be doing now")?
maybe a way to specify some sort of desired state, and query which motions you should propose to get from here to there?
maybe "beginner/intermediate/advanced" user levels?
should make it very quick to change state, so that you can follow the debate with minimal attn to the computer. single-key hotkeys to select most common actions. shouldn't require one to specify details about the state (i.e. what exactly is being proposed) if you don't want to.
should store history, so that you can use it later to recall a history of the meeting
(and also, so that you can use the "back" button like in a browser)
maybe actions which are "valid" as far as the software can check, but which contain some additional unformalized semantic conditions for the user to interpret, should be colored a different color (like, yellow instead of green; maybe only the border?). maybe common conditions should get to specify their own colors (i.e. each motion might be allowed to specify a "color if uncheckable constraint" attribute) (for example, "reconsiderable if business has been transacted" is probably a common one)
maybe color is too strong a signal (i.e. yellow motions vs. green motions might be disparaging to the yellow ones). maybe, say, solid vs. dashed border would be more appropriate and less confusing to newcomers ("that dang motion never turns green!")