FfiiKonfPoll0511En

General Assembly 2005-11-29 Brussels, Online Poll

[ Assembly 2005-11-29 | Agenda | Poll Results | Poll Documentation ]

NEW: Poll results (short) and documentation (long)

As indicated in our Nov 15 alert, our General Assembly will take place in Brussels on November 29, 15:00-18:00 at 13-15 rue des Ateliers (near Place Sainctelette) at the location of iMatix Corporation.

You can find more details at the conference and agenda pages.

With regard to item 9 of the agenda, election of president and board members, we are carrying out an electronic poll among FFII members. Actually, the results of this poll are not binding in any way, but are of interest for the General Assembly nevertheless. You can participate in the poll by replying to the polling e-mail with the contained form filled out.

In order for your reply to be processed, it must arrive until Sunday November 27, 22:00 UTC (note the timezone). The processing of your reply is completely automated, therefore questions or comments won't be noticed. In order to prevent vote duplication, and to enable recounting, your vote(s) will be stored in the FFII database with an anonymized user id. This also enables modification of votes by re-submission. After the General assembly, all e-mail replies to the poll are deleted, and the individual votes are deleted from the database.

How do we know it's you?

The automaton behind feedback AT ffii org does not examine your e-mail address in order to identify you. In fact, you could try manipulating your "From" address field in any way you like, but this will not impress the feedback system at all.

We use another trick. The mail with our poll form contains a (usually invisible) "Message-Id" field in its header with information about what this mail is about and to whom it has been adressed. When you press "reply" in your mail client, the contents of that field are automatically copied into the (usually invisible) "In-Reply-To" field of your reply. Once the feedback processor receives a mail with such a field, it can extract the necessary information from there.

Note that this mechanism only works when "reply"ing. Using a "forward" function does not set the "In-Reply-To" field, consequently our feedback processor cannot recognize such mails. This means that you have to "reply" directly; should you ever lose the mail with the form, you cannot simply get the form from elsewhere and draft a reply from that: It would not be processed. This is like losing the invitation to an election.

The Message-Id also includes some random data and a checksum to prevent hacking.

How to specify a vote

Votes are specified in the lines containing checkboxes. The checkbox lines may be indented by some string, e.g. the ">" commonly used for quoting, but must not be broken into several lines thereby, because re-wrapped form lines are unlikely to be recognized by the receiving automaton.

Should the same form line happen to occur several times in a reply (due to repeated follow-ups or whatever), the least-indented line will be used, assuming that this is the most recently typed line. If some ambiguity still remains because of several lines with the same (least) indentation, the first of these lines is used. This latter rule is meant to handle quoting styles where older messages are placed at the end without any indentation marks.

Examples for valid choices in a checkbox are

Still valid, although exaggerated, examples are

Although these allow the specification of more than just boolean values, such specifications are reduced to a boolean value by simply testing their positiveness. That is,

are all equivalent after reduction and share the meaning of "yes", and

are all equivalent after reduction and share the meaning of "no".

Examples of invalid specs are uses of unknown or mixed characters:

Finally, we have to deal with the empty spec which is usually the default setting:

These may best be interpreted as "abstention", but by most people, they are intuitively interpreted as equivalents to a "no", and therefore we have to ensure that the subtle difference has as little effect as possible. One way to accomplish this is to provide every alternative to a choice explicitly, in its own form line. This leads us to the concept of groups.

Treatment of groups of form lines

In general, a group comprises adjacent form lines with semantic dependencies. For example, votes for M positions among N candidates are presented as a group

with N form lines and up to M "yes" votes allowed. In our current poll, we have four groups of form lines: one group for the president vote, one (degenerated) group for the treasurer vote, and one group for each of the two board vote scenarios.

Each group is treated as a unit: Depending on the contents of its form lines, either the entire group is accepted as a valid set of votes, or the entire group is treated as being invalid. Being invalid essentially means being ignored. Being ignored means that the database will not be updated with data from that group.

Note that this means that a valid group vote from a previous reply by the same person cannot be erased or overridden by a subsequent invalid group vote. Only valid group votes can enter the database.

In a group with alternative options, or at least a restrictive upper limit on "yes" votes, empty checkboxes are assumed to mean "no". Missing form lines from the same group are treated as if they were present with the original default setting, which is an empty checkbox. Combined, these rules mean that if you just mention

and delete all other form lines of the group, then all other candidates will be given a "no". If, in a later reply to the same mail, you change your choice to

then candidate 1 will get a "no" again, even if you do not state that explicitly.

In sum, this means that you have to specify every "yes" vote that you want to keep. That in turn means that any restriction on the number of "yes" votes can immediately be checked by looking at the message itself. No further knowledge about possible votes from previous replies is necessary. A group with too many "yes" specifications is considered invalid and hence will be ignored.

The rule about missing form lines has been extended to form lines with invalid contents: As long as no valid "yes" symbol is encountered in a checkbox, a "no" will be assumed. The alternative approach, treating the entire group as invalid, has been considered too drastic since that would invalidate even correct "yes" votes in other form lines from the same group.

However, when a group of form lines contains no valid "yes" or "no" specification at all (as is the case when replying to the poll with an unedited form), then no willful specification is assumed, and the entire group will be ignored rather than interpreted as a complete group of "no"s. As mentioned before, ignored groups do not alter the database. Note however that you can still get a group with all "no"s into the database: by specifying a valid "no" token (e.g. "-") in at least one checkbox of the group. The principle is that you have to fill at least some places in, otherwise you won't change anything. This is important because e-mails often are handled, and replied to, by automata.

Hosting sponsored by Netgate and Init Seven AG