PsyOps 007: Paul Tagliamonte wanted Debian Press Team to have license to kill

We publish a fresh email from Paul Tagliamonte, the White House staff member who encouraged fellow Debianists to defame Dr Appelbaum. This email is the strongest yet, while most volunteers wanted to remain neutral, Tagliamonte was calling for the Press team to make these hits without consulting the volunteers at all.

Subject: 	Re: Expulsion of Jacob Appelbaum 
Date: 	Tue, 21 Jun 2016 07:37:43 -0400
From: 	Paul R. Tagliamonte 
To: 	Russell Coker 
CC: 	Debian Private List 



Seems like a thing the Press team could help coordinate.

On Jun 21, 2016 7:27 AM, "Russell Coker" > wrote:

http://www.itwire.com/business-it-news/open-source/73441-appelbaum-banned-from-debian-events-after-sexual-misconduct-charges.html

Well the DPL has decided to go public about it after all.

In future I think it would be better to have a plan for these
things. To have an argument on this list about whether information
should be released while the DPL is sending it all to a journalist
isn't the way things should go.

On 21 June 2016 8:57:56 PM AEST, Jonathan Dowland > wrote:
>Please do not CC me, I am subscribed to the list.
>
>On Tue, Jun 21, 2016 at 08:04:01PM +1000, Russell Coker wrote:
>> Mattia suggests that it's already public that he was expelled for
>anyone who
>> knows how to interpret it.
>>
>> Why can't we just state it outright instead of leaving clues in
>Wikipedia?
>> The social contract says that we won't hide problems. Why are we
>trying to
>> hide this problem?
>
>I don't think Debian has taken ownership of whatever is written on
>Wikipedia,
>but we certainly aren't hiding it: It's there on the NM page in plain
>sight.
>There's a big difference between hiding something and making an active
>effort
>to draw attention to it.
>
>The action that has been taken has been for the sake of the safety and
>well
>being of other Debian members, NOT as some kind of white-knight
>publicity
>stunt. There's no *need* to shout it from the rooftops as that does not
>further the former goal.

--
Sent from my Samsung Galaxy Note 3 with K-9 Mail.

How to wreck your organization with PsyOps techniques, from the OSS Simple Sabotage Field Manual

This email was sent on public mailing lists and responses are available there. What was Tagliamonte's real aim in circulating this? Was it an example of boasting about the second expulsion of Dr Norbert Preining?

Subject: History doesn't repeat itself, but it often rhymes
Date: Tue, 22 Feb 2022 12:29:53 -0500
From: Paul Tagliamonte 
To: Debian Devel , debian-project@lists.debian.org

Hello, Debianites,

Allow me, if you will, to talk a bit about something that's been on my mind
a bit over the last handful of years in Debian. It's something that's pretty
widely circulated in particular circles, but I don't think I've seen it on
a Debian list before, so here's some words that I've decided to put together.


I've intentionally not drawn lines to the 'discussions' going on (or the
'discussions' in the past I could point to) to avoid getting dragged into more
thrash, so if you reply, please do try to keep this clear of any specific
argument that you feel this may or may not apply to. This is a more general
note that I think could use some thought from anyone who's interested.


During World War II, the OSS (Office of Strategic Services)[1] distributed a
manual[2] (the Simple Sabotage Field Manual), which was used to train
"citizen-saboteur" resistance fighters, some of whom were told, not to pick up
arms, but to confound the bureaucracy by tying it up with an unmanageable
tangle of "innocent" behavior.

While no one is working within the Debian community member attempting to
subvert us sent from the shady conglomerate of nonfree operating systems by
following this playbook, this playbook is an outstanding illustration of how
some innocent behavior can destroy the effectiveness of an organization.  It's
effective, precisely *because* it's not overly malicious, and these behaviors
-- while harmful -- are explainable or innocent. Section (3) covers this in
detail.

Most of the OSS Simple Sabotage Field Manual covers things like breaking
equipment or destroying tanks, but section (11) is "General Interference with
Organizations and Production". I'm just going to focus here.

Let's take a look at section (11):

> (1) Insist on doing everything through "channels." Never permit short-cuts
>     to be taken in order to expedite decisions.
>
> (2) Make "speeches." Talk as frequently as possible and at great length.
>     Illustrate your "points" by long anecdotes and accounts of personal
>     experiences. Never hesitate to make a few appropriate "patriotic" comments.
>
> (3) When possible, refer all matters to committees for "further study and
>     consideration." Attempt to make committees as large as possible -- never
>     less than five.
>
> (4) Bring up irrelevant issues as frequently as possible.
>
> (5) Haggle over precise wordings of communications, minutes, resolutions.
>
> (6) Refer back to matters decided upon at the last meeting and attempt to
>     re-open the advisability of that decision.
>
> (7) Advocate "caution." Be "reasonable" and urge your fellow co-conferees to
>     be "reasonable" and avoid haste which might result in embarrassments or
>     difficulties later on.
>
> (8) Be worried about the propriety of any decision - raise the question of
>     whether such action as is contemplated lies within the jurisdiction of
>     the group or whether it might conflict with the policy of some higher
>     echelon.

I won't go through each of these point-by-point since everyone reading this is
likely sharp enough to see how this relates to Debian (although I will point
out I find it particularly interesting to replace "patrotic" here with the
Debian-specific-patriotism -- Debianism? -- and re-read some of the more
heated threads)



I have a theory of large organizations I've been thinking a lot about that came
from conversations with a colleague, which is to think about an organization's
"metabolic overhead" -- i.e., the amount of energy that an organization
devotes to intra-organization communication. If you think about a car
manufacturing plant, the "metabolic overhead" is all the time spent on things
like paperwork, communication, planning. It's not possible (or desirable!) for
an organization to have 0% overhead, nor is it desirable (although this one *is*
possible) to spend 100% time on overhead. I think it *may* be possible to get
to above 100% overhead, if workplace contention spills out into drinks after
work.

All of the points in the OSS Simple Sabotage Manual are things designed to
increase the metabolic overhead of an organization, and to force organization
members to spend time *not* doing their core function (like making cars,
running trash pickup or ensuring the city has electricity), but rather, spend
their time litigating amongst themselves as the core function begins to
become harder and harder to maintain. This has the effect of degrading the
output/core function of an organization, without any specific cause
(like a power loss, etc).

I'd ask those who are reading this to consider how this relates to their time
spent in Debian. Is what you find something you're happy about with a hobby
project you're choosing to spend your free time on? Are you taking actions to
be a good participant?



To do a bit of grandstanding myself, do remember that it's not just your time
here -- when we spend significant resources litigating and playing bureaucracy
games, we spend others' time as well. People on the committees you refer matters
to, all project members in the case of a GR, all the Mailing List readers --
and that's all time that is taken from building and maintaining an operating
system. The output becomes degraded. There's no specific acute cause like
a buildd failure.

When I think about how Simple Sabotage works, I find myself unable to shake the
feeling that the best way to combat the organizational dysfunction outlined in
the OSS's Simple Sabotage Manual is to avoid "taking the bait", and to ensure
small, highly empowered teams of do-ers are able to execute. We need to avoid
being dragged into development by consensus -- while understanding that
communication and collaboration are good. We need to ensure that individuals
that continue to exhibit the behaviors contained within the Simple Sabotage
Manual understand the harm that can come from a system of individuals taking
actions like them -- even if their intent is sincere and come from a
constructive, helpful place. In some cases, ignoring the "sabotage"[3] outright
will work, in other cases, perhaps a gentile and respectful private note
letting them know that their suggestion is actively harmful and to consider not
doing it again. Engaging publicly makes things worse, since it will continue to
suck people's time into litigating the "sabotage" (which is, itself, becomes
"sabotage").

Taking an expensive action (like referring to a committee, re-opening an
old decision, arguing about the precising wording and associated pedantry,
and questioning the authority of those doing work) should only be done
if the cost outweighs the benefit.

We don't need to be hostile or expel people for doing things outlined in the
OSS Simple Sabotage Manual, since a lot of that behavior is -- at times --
desirable, but I think we do need a *LOT* of self-reflection (from *everyone*
who actively engages with Debian politics) to consider our actions, and
determine how (if at all) we feel that we (as individuals) should change.

Please don't beat eachother up with this calling each other saboteurs and
claiming that everyone's emails are "sabotage", but please do consider
using this mental framework when looking at our discussions from time to
time.

With love!
   paultag


[1]: Of its many notable members, Julia Child was the first one I think
    of -- yes, that Julia Child!
[2]: https://www.gutenberg.org/files/26184/page-images/26184-images.pdf
[3]: //maybe// not the best word, but I'm using it here for internal consistency