[liberationtech] Use of gender-neutral terms when speaking and writing

Wed Jun 12 14:07:24 PDT 2013

Dear list,

FYI, the standard practice at Stanford (and many other universities and
Fortune 500 corporations) is to use gender-neutral terms when speaking or
writing.  Doing otherwise is considered disrespectful.

Of course, everyone has a right to free speech.  But, if someone is
disrespectful, the reader also has a right to get angry, especially when
the writer's comments are deemed insensitive to 50%+ of the population.

Fortunately, many on the list have already made this point, so let's move
on.

Thanks,
Yosem, one of the list moderators

On Wed, Jun 12, 2013 at 1:48 PM, Brian Conley <brianc at smallworldnews.tv>wrote:

> +1 Micah
>
> +1 Jillian Anne and Paul.
> On Jun 12, 2013 7:24 PM, "micah" <micah at riseup.net> wrote:
>
>>  Eleanor Saitta <ella at dymaxion.org> writes:
>>
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA256
>> >
>> > On 2013.06.12 11.54, micah wrote:
>> >> I'm constantly hearing from people who complain about the UI in
>> >> things like gnupg. I feel your pain, I do not want to argue that
>> >> you are wrong. However, I do want to argue that complaining doesn't
>> >> help to solve the problem. I've asked every single person who has
>> >> complained about this problem to me recently, "have you filed a bug
>> >> about your issues?" and everyone's response is: "no".
>> >>
>> >> I've done this, and guess what? It works! I filed bugs and had
>> >> discussions on the gnupg mailing list that have made your
>> >> experience with that tool a little bit better. There are many ways
>> >> that I think it can be improved still, don't get me wrong, but the
>> >> gnupg developers are reasonable people who want to make the
>> >> software better, and probably have been hearing these complaints
>> >> for years and years and would welcome a way to make people stop
>> >> complaining.
>> >>
>> >> It seems there are a lot of people out there who have a clear idea
>> >> of what is good and what is bad UI and are pretty vocal about when
>> >> something is bad. How about turning that into clear bugs that
>> >> describe better workflow and UI? You dont have to be a crypto nerd,
>> >> or a C programmer to make this stuff better and easier to use.
>> >
>> > Is there any point in filing a bug that says "Please have a
>> > professional designer re-work all use flows in this system from
>> > scratch"?  (No.)
>>
>> I agree, there is not much point in that.
>>
>> > Is there any point in filing a bug that says "Please remove features
>> > X, Y, Z, Q, R, N, and M because they're too confusing for novice
>> > users"?  (No, especially when X is "the entire web of trust".)
>>
>> I somewhat disagree with you on this point. There is a point to filing a
>> bug that says, "Please remove the choice of RSA/DSA/Elgamal from the gpg
>> --gen-key process and just automatically use the default unless the user
>> has passed --advanced. It is confusing for a user who is just learning
>> to use the tool to have to make this choice."
>>
>> > "Filing bugs" isn't enough -- it's an entire design effort.
>>
>> I do not think that it is one or the other. Don't throw out the bugs or
>> usability enhancements because you think that the whole thing needs to
>> be redesigned.
>>
>> > Individuals may see a thing and think "hey, this could be changed",
>> > but what's needed is a top-to-bottom redesign, and that does not
>> > translate into a simple set of "clear bugs".  I don't believe that the
>> > GPG designers have the resources available to do this design effort as
>> > it stands, and it's not just them, it's the entire ecosystem that
>> > needs to be involved and work together.
>>
>> I disagree. I've been working with people who have been doing this sort
>> of iterative changes with the software for years and things have gotten
>> better.
>>
>> It is actually not that hard to make significant usability changes
>> without needing to make top-to-bottom changes.
>>
>> For example, here is a bug I filed which coalesces my experiences doing
>> gnupg trainings with different activists and the stumbling blocks that
>> we ran into:
>>
>>
>> https://bugs.g10code.com/gnupg/issue1506?@ok_message=msg%204634%20created%0Aissue%201506%20created&@template=item
>>
>> > We'd love to see this fixed.  If it was this easy, it would have been
>> > done years ago.
>>
>> You would be surprised the changes that you can get if you ask for
>> them and describe clearly why they are needed. It helps a lot if you can
>> also clearly describe a better alternative. If you know how to code and
>> have time, then providing a patch will go even further. Although patches
>> are always welcome, they are not required.
>>
>> For a really long time, smart cryptographers have been writing this
>> software, their heads are focused on doing the correct technical thing
>> and that doesn't always translate into an easy experience. They have
>> been doing this so long that they cannot see how this could be any
>> different. It is up to us who aren't so deeply stewed in hashing
>> algorithms and trust metrics, we who work with people who provide us the
>> feedback who can synthesize it and bring that back to those people in
>> who know the code so that they can make it more usable.
>>
>> If we do not do that, it will not happen, ever. No matter how much we
>> complain in places where they will never hear us.
>>
>> My experience has been that software gets better when I point out the
>> problems to the appropriate place that the developers have asked for
>> those things to be put. Sometimes that takes several years, sometimes I
>> get lucky and the change happens in a weekend. It very rarely gets
>> better on its own.
>>
>> You may think that the whole crypto world needs to be thrown out and we
>> need to start again, and you see that as an intractably impossible
>> problem. I see things differently because I've seen annoying things
>> iteratively become usable over time, and I've seen usable things become
>> frustrating and unusable after a design overhaul. The only way either of
>> those things work is if you involve users in the feedback loop. You
>> can't just redesign everything and then throw it out there without doing
>> user testing to figure out what design assumptions you made are not
>> shared with others.
>>
>> We are the intermediaries between those who code and those who use, if
>> we fail to do our job we have only ourselves to blame.
>>
>> micah
>>
>> --
>> Too many emails? Unsubscribe, change to digest, or change password by
>> emailing moderator at companys at stanford.edu or changing your settings at
>> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>>
>
> --
> Too many emails? Unsubscribe, change to digest, or change password by
> emailing moderator at companys at stanford.edu or changing your settings at
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20130612/b9fd9963/attachment.html>