Showing posts with label mail. Show all posts
Showing posts with label mail. Show all posts

Thursday, July 30, 2020

Voting: Should It Be Hard?

An argument for how more access to voting (not less) is not only fair but makes for a more deliberative voting population (also posted on Medium).

Image of “Vote” with three hands of different color shades reaching up toward it. Public domain image via Mohamed Hassan.
(public domain image from Mohamed Hassan)
“Voting should take some effort. It means more that way.”

This was a statement I copied from a social media post of an old acquaintance, but I have heard the same sentiment from many others. They say that voting is important, perhaps the most important assertion of someones feelings that they can make, and so a certain amount of inconvenience is necessary to adequately motivate someone to deliberate on important options and make an informed choice. This logic usually then takes a leap and leads to the conclusion that all voting should be in person; mail-in voting is “too easy” to encourage people to make good choices.

However, the danger of using in-person voting as an explicit barrier to entry to filter out those who do not “care enough” about voting is that the burden of in-person voting is not the same across an entire population. Thus, accepting in-person voting as the mechanism that imposes costs (and requires effort) is an implicit statement that some votes are less valuable than others not because the voter cares less but because the voter happens to be more burdened by the process of in-person voting. But voting is meant to be a vehicle for those who will be affected by government actions to have a voice in deciding who will make up the government that takes those actions. Those who are the most burdened by lack of infrastructure, for example, should certainly not be attenuated; if anything, their voices should be amplified.

Furthermore, it is false to suggest that voting by mail is far easier than voting in person. Voting by mail requires considerable deliberation, care, and effort to complete. Just because someone receives a ballot in the mail (which they may have had to go through a process to register to receive) does not mean that they will open it, complete it (perhaps bubbling in tens to hundreds of bubbles), package it properly to return, and deposit to a mailbox. You could argue that if someone lives next to a polling location, it would be much easier to wander in and vote electronically with little deliberation (just tapping randomly on a screen) than it would be to actually fill out and return a mail-in ballot properly. In fact, if we were to abolish in-person voting entirely so that everyone would have to vote by mail, my guess is that many voters who found in-person voting very convenient might start skipping some elections because they couldn’t be bothered with the longer process of mail-in voting.

And that’s the big point — asymmetries of convenience create biased voting demographics. The issue is not that voting by mail is “so convenient” (because it isn’t!); it is that voting in person is, for some, prohibitively inconvenient. There should be a space for both kinds of voting (and possibly more). If we really want a representative sample of a population, we have to ensure our sampling methods do not inadvertently (or otherwise) exclude parts of the population that will be affected by the outcome of the process of voting that they were excluded from.

If you really do want voting to “take some effort”, it should be motivational effort that is equally applicable to everyone and not physical effort that varies from person to person or community to community. Where do we get that motivational-effort barrier? From very large numbers of people voting. If large numbers of people vote, then each person feels that their vote is inconsequential, and so the costs of voting will always be larger than the benefits. This surplus in the costs of voting will always present a motivational barrier, and the size of that barrier will be similar across the large population of voters. Thus, magnifying the costs of voting is best accomplished by magnifying the number of people voting; it is poorly accomplished by magnifying the physical distance between some voters and their voting location.

Thursday, September 01, 2011

Why GMail's show-if-unread is NOW useless with nested labels

Once upon a time, when they were both in "GMail Labs", the show-if-unread feature and nested labels features worked together seamlessly.
  • nested labels: You could create a nested label (like a subfolder) by adding slashes in folder names. You would create two folders called "Parent/ChildA" and "Parent/ChildB", and they would be displayed as "ChildA" and "ChildB" underneath a single "Parent" that you could collapse and expand.
  • show-if-unread: Only labels that had unread messages in them would show up in the left bar. To see all of your labels, you could use the "more" link which would show you a full list.
In the case where a nested label had unread messages in it, it would show up in its flat form (if I recall correctly) in the list. So you'd see "Parent/ChildA" but "ChildB" would still be nested under "Parent" in the "more". That was fantastic.

However, eventually both labs features became integrated into production GMail, and they messed it all up. Now, ostensibly to avoid revealing the slash form and to avoid having parent labels repeated in both the unread and read lists, they've made it impossible to apply show-if-unread to nested labels. Consequently, if any nested labels have unread messages in it, the parent and all of its nested labels show up in the unread list. So you get things like this (click for larger):
Obviously, that defeats the whole purpose of show-if-unread. I'm forced to look at all of those read nested labels just because some of their "sublings" are unread.

So Google has gone from taking two nice features and combining them into one terrible and useless and awful thing.

Wednesday, June 27, 2007

Pine, PASSFILE, all-patch, and Thunderbird 2.0 IMAP keywords

Thunderbird 2.0 has been released! It's fast and finally supports an arbitrary number of custom IMAP keywords (IMAP keywords are similar to the labels used in GMail). I'm thrilled about this.

However, regardless of how wonderful Thunderbird gets, I will always keep PINE around (which has supported IMAP keywords for a long time).

When I build PINE for my systems, I usually pick up a few of the most popular patches as well. I never noticed that there was an all of the above patch that packages ALL of the most popular patches, new features, and bug fixes. I think this is pretty exciting too.

To build PINE with PASSFILE support (i.e., support for saving passwords to file), I recommend using the infinite ink instructions:
#!/bin/sh
./build clean
./build 'EXTRACFLAGS=-DPASSFILE=\".pine.pwd\"' osx
# ^^^
# platform
You can find a list of platforms in the doc/pine-ports file. Some common ones include (see the document for any special build instructions):
    BSD (original BSD 4.3 from U.C. Berkeley)
bsd BSD 4.3

BSDi
bs3 BSDi BSD/386 Version 3 and Version 4
bs2 BSDi BSD/386 Version 2
bsi BSDi BSD/386 Version 1

Cygwin
cyg Cygwin environment under Windows

HP-UX
hpx HP-UX 10.x
hxd HP-UX 10.x w/ DCE
ghp HP-UX 10.x using gcc
hpp HP-UX 8.x and 9.x
shp HP-UX 8.x and 9.x w/ TCB
gh9 HP-UX 8.x and 9.x using gcc

Linux
lnx Linux using crypt from the C library
lnp Linux using PAM
slx Linux using -lcrypt for crypt()
sl4 Linux using -lshadow for crypt()
sl5 Linux using shadow passwords
ldb Debian Linux
lmd Mandrakelinux
lrh RedHat Enterprise and RedHat 7.2 or later
lsu SuSE Linux

Macintosh
osx Macintosh OS X
ox2 Macintosh OS X 10.2 and earlier

NetBSD
neb NetBSD

OpenBSD
bso OpenBSD w/ shared-lib

QNX
nto Neutrino

SCO
sc5 SCO Open Server 5.x
go5 SCO Open Server 5.x using gcc
sco SCO Unix
gsc SCO Unix using gcc

Sun Solaris (Solaris 9 is the same as SunOS 5.9)
gs5 Sun Solaris >= 2.5 using gcc
soc Sun Solaris >= 8 using Sun C
gs4 Sun Solaris <= 2.4 using gcc
so5 Sun Solaris >= 2.5 (try soc or gs5)
so4 Sun Solaris <= 2.4

Sun SunOS (This is pre-Solaris SunOS)
sun Sun SunOS 4.1
ssn Sun SunOS 4.1 w/ shadow passwords
gsu SunOS 4.1 using gcc
s40 Sun SunOS 4.0

System V Release 4
sv4 System V Release 4

Windows
wnt Windows NT 3.51
Happy mailing!