Re: [s-d] Re: Webmaster's Poll

["Daniel Peter Lepage" <dpl33@xxxxxxxxxxx>]

> "Daniel Peter Lepage" <dpl33@xxxxxxxxxxx> writes:
>> So, imagine that I were to rewrite some of the scripts surrounding the
>> Ministry of Change. What features would be most useful?
>>
>> Specifically, how important are the following features:
>>
> (note: I've reordered this list slightly to comment on it in different
> groupings)
>
>>  * Remembering previous revisions of current proposals
>>  * Providing diff-style comparisons of prop revisions
>
> Especially when a revision is first submitted, having a "diff" somehow
> can be very helpful. But going back and seeing older versions doesn't
> seem *that* useful, although you never know when you might want to.
> If possible, it might be need to use the wiki's built-in history and
> diff-ing features... Maybe props should just be pages... and then when
> editing them, we could see the formatting and such, too. However, I
> have no idea how feasible that is to set up.

Wouldn't be too hard to do. The only difficulty is that the scripts need
to be able to parse the whole prop, which means certain characters need to
be in the right places in all props. Then if you use the wiki's editing
you'll have to be very careful what you type, since even small things like
moving a headline could destroy the scripts' ability to parse it.

>>  * Remembering previous revisions of historical proposals
>>  * Submitting prop/voting info via email
>
> Those doesn't seem that particularly useful.
>
>>  * Searching current or historical proposals
>>  * Viewing all proposals from a given time period
>
> That could be nice. When implementing the changes from the previous
> nweek, it'd be nice to see the text of "all props that passed from the
> previous nweek", and I could see it being interesting to do more
> complicated searches, to see how things were on a particular nweek, or
> going back to look up some older proposal that you know someone once
> did, but now would be perfect to adapt, or something.

Searching becomes a lot faster if I put them in a database. Storing the
pass/fail state is also a good idea (we don't do that right now).

>>  * Handling things like the Legislator of the Nweek and the Big Rubber
>> Stamp through the voting web forms
>
> I don't know if you need to handle those kinds of things explicitly,
> but giving the Minister of Change to give arbitrary changes to the
> final totals in order to handle such things might be a nice addition.

At the moment e already can, since the results get spit up as text and e
can do whatever e wants before sending it out. But if we start
automatically storing pass/fail information, this will get more
complicated.

>>  * Periodically emailing out the text of props, votes, etc.
>
> I think I'd prefer it to email out a link to the voting page and list
> of active props page at the start of the voting period. There's no
> reason a minister would need to do that manually.
>
>>  * Loading pages quickly (The PropIndex page is an example of *not*
>> loading quickly)
>
> Well, it doesn't seem *that* bad, particularly for searches like that
> where it wouldn't happen that often. But much longer than that starts
> to get annoying.
>
>>  * Easy transfer of Ministerial Power
>
> It seemed easy enough for you to transfer the power to me, when I
> first took over the position when you went on vacation shortly after I
> arrived at the game.

True, but not as easy as it should have been - I had to go add your name
to a script on the server, which means that anytime the position changes
hands the WebMinister will have to be involved. That'll need fixing.

>>  * Any other features you can think of
>
> A scripting language for changes to the rules, so that passed props
> can just be executed automatically. (I'm half-joking here, but it
> seems kind of silly that most of what I do every nweek is copying
> stuff from a prop and pasting it into a rule.) Maybe just hyperlinks
> to the affected rules would be a good start.

We've discussed things like that before, actually; my stance on it is that
if somebody gives me a program that takes a rule text and a prop text and
returns the new rule text based on some language, then I'll add it to the
scripts, but I won't be able to write such a thing myself.

If we were to have such a scripting language, it wouldn't have to be very
complicated, would it? You'd have maybe four commands,

#Create [a] Rule in <rulebook #>.<section #>
  <Rule>

#Modify Rule <rulebook #>.<section #>.<id #> to read
  <Rule>

#Repeal Rule <rulebook #>.<section #>.<id #>

#In Rule <rulebook #>.<section #>.<id #>, replace
  <foo>
#with
  <bar>

Analogous things could perhaps be set up to do the same for entire
sections or even entire rulebooks...

-- 
Wonko

_______________________________________________
spoon-discuss mailing list
spoon-discuss@xxxxxxxxx
http://lists.ellipsis.cx/mailman/listinfo/spoon-discuss