Latest posts for tag talk

Introducing Debusine

Abstract

Debusine manages scheduling and distribution of Debian-related tasks (package build, lintian analysis, autopkgtest runs, etc.) to distributed worker machines. It is being developed by Freexian with the intention of giving people access to a range of pre-configured tools and workflows running on remote hardware.

Freexian obtained STF funding for a substantial set of Debusine milestones, so development is happening on a clear schedule. We can present where we are and, we're going to be, and what we hope to bring to Debian with this work.

pdo debian eng talk

Adulting

Abstract

Although Debian has just turned 30, in my experience it has not yet fully turned adult: we sometimes squabble like boys in puberty, like children we assume that someone takes care of paying the bills and bringing out the trash, we procrastinate on our responsibilities and hope nobody notices.

At the same time, we cannot assume that people have the energy and motivation to do what is needed to keep the house clean and the boat afloat: Debian is based on people volunteering, and people have diverse and changing reasons to be with us, and private lives, loved ones and families, bills to be paid.

I want to start figuring out how to address practical issues around the sustainability of the Debian community, in a way that fits the needs and peculiarities of the Debian community.

The end does not justify the means: really, the means define what the end will be. I want to talk about the means: how to be sustainable, how to be interesting, how to be fun, how to have a community worth caring for, how to last for centuries

pdo debian eng talk

Deconstruction of the DAM hat

Further reading

Talk notes

Intro

  • I'm not speaking for the whole of DAM
  • Motivation in part is personal frustration, and need to set boundaries and negotiate expectations

Debian Account Managers

  • history

Responsibility for official membership

  • approve account creation
  • manage the New Member Process and nm.debian.org
  • close MIA accounts
  • occasional emergency termination of accounts
  • handle Emeritus
  • with lots of help from FrontDesk and MIA teams (big shoutout)

What DAM is not

  • we are not mediators
  • we are not a community management team
  • a list or IRC moderation team
  • we are not responsible for vision or strategic choices about how people are expected to interact in Debian
  • We shouldn't try and solve things because they need solving

Unexpected responsibilities

  • Over time, the community has grown larger and more complex, in a larger and more complex online environment
  • Enforcing the Diversity Statement and the Code of Conduct
  • Emergency list moderation
    • we have ended up using DAM warnings to compensate for the lack of list moderation, at least twice
  • contributors.debian.org (mostly only because of me, but it would be good to have its own team)

DAM warnings

  • except for rare glaring cases, patterns of behaviour / intentions / taking feedback in, are more relevant than individual incidents
  • we do not set out to fix people. It is enough for us to get people to acknowledge a problem
    • if they can't acknowledge a problem they're probably out
    • once a problem is acknowledged, fixing it could be their implementation detail
    • then again it's not that easy to get a number of troublesome people to acknowledge problems, so we go back to the problem of deciding when enough is enough

DAM warnings?

  • I got to a point where I look at DAM warnings as potential signals that DAM has ended up with the ball that everyone else in Debian dropped.
  • DAM warning means we haven't gotten to a last resort situation yet, meaning that it probably shouldn't be DAM dealing with this at this point
  • Everyone in the project can write a person "do you realise there's an issue here? Can you do something to stop?", and give them a chance to reflect on issues or ignore them, and build their reputation accordingly.
  • People in Debian should not have to endure, completey powerless, as trolls drag painful list discussions indefinitely until all the trolled people run out of energy and leave. At the same time, people who abuse a list should expect to be suspended or banned from the list, not have their Debian membership put into question (unless it is a recurring pattern of behaviour).
  • The push to grow DAM warnings as a tool, is a sign of the rest of Debian passing on their responsibilities, and DAM picking them up.
  • Then in DAM we end up passing on things, too, because we also don't have the energy to face another intensive megametathread, and as we take actions for things that shouldn't quite be our responsibility, we face a higher level of controversy, and therefore demotivation.
  • Also, as we take actions for things that shouldn't be our responsibility, and work on a higher level of controversy, our legitimacy is undermined (and understandably so)
    • there's a pothole on my street that never gets filled, so at some point I go out and fill it. Then people thank me, people complain I shouldn't have, people complain I didn't fill it right, people appreciate the gesture and invite me to learn how to fix potholes better, people point me out to more potholes, and then complain that potholes don't get fixed properly on the whole street. I end up being the problem, instead of whoever had responsibility of the potholes but wasn't fixing them
  • The Community Team, the Diversity Team, and individual developers, have no energy or entitlement for explaining what a healthy community looks like, and DAM is left with that responsibility in the form of accountability for their actions: to issue, say, a DAM warning for bullying, we are expected to explain what is bullying, and how that kind of behaviour constitutes bullying, in a way that is understandable by the whole project.
  • Since there isn't consensus in the project about what bullying loos like, we end up having to define it in a warning, which again is a responsibility we shouldn't have, and we need to do it because we have an escalated situation at hand, but we can't do it right

House rules

Interpreting house rules

  • you can't encode common sense about people behaviour in written rules: no matter how hard you try, people will find ways to cheat that
  • so one can use rules as a guideline, and someone responsible for the bits that can't go into rules.
    • context matters, privilege/oppression matters, patterns matter, histor matters
  • example:
    • call a person out for breaking a rule
    • get DARVO in response
    • state that DARVO is not acceptable
    • get concern trolling against margninalised people and accuse them of DARVO if they complain
  • example: assume good intentions vs enabling
  • example: rule lawyering and Figure skating
  • this cannot be solved by GRs: I/we (DAM)/possibly also we (Debian) don't want to do GRs about evaluating people

Governance by bullying

  • How to DoS discussions in Debian
    • example: gender, minority groups, affirmative action, inclusion, anything about the community team itself, anything about the CoC, systemd, usrmerge, dam warnings, expulsions
      • think of a topic. Think about sending a mail to debian-project about it. If you instinctively shiver at the thought, this is probably happening
      • would you send a mail about that to -project / -devel?
      • can you think of other topics?
    • it is an effective way of governance as it excludes topics from public discussion
  • A small number of people abuse all this, intentionally or not, to effectively manipulate decision making in the project.
  • Instead of using the rules of the community to bring forth the issues one cares about, it costs less energy to make it unthinkable or unbearable to have a discussion on issues one doesn't want to progress. What one can't stop constructively, one can oppose destructively.
  • even regularly diverting the discussion away from the original point or concern is enough to derail it without people realising you're doing it
  • This is an effective strategy for a few reckless people to unilaterally direct change, in the current state of Debian, at the cost of the health and the future of the community as a whole.
  • There are now a number of important issues nobody has the energy to discuss, because experience says that energy requirements to bring them to the foreground and deal with the consequences are anticipated to be disproportionate.
  • This is grave, as we're talking about trolling and bullying as malicious power moves to work around the accepted decision making structures of our community.
  • Solving this is out of scope for this talk, but it is urgent nevertheless, and can't be solved by expecting DAM to fix it

How about the Community Team?

  • It is also a small group of people who cannot pick up the responsibility of doing what the community isn't doing for itself
  • I believe we need to recover the Community Team: it's been years that every time they write something in public, they get bullied by the same recurring small group of people (see governance by bullying above)

How about DAM?

  • I was just saying that we are not the emergency catch all
  • When the only enforcement you have is "nuclear escalation", there's nothing you can do until it's too late, and meanwhile lots of people suffer (this was written before Russia invaded Ukraine)
  • Also, when issues happen on public lists, the BTS, or on IRC, some of the perpetrators are also outside of the jurisdiction of DAM, which shows how DAM is not the tool for this

How about the DPL?

  • Talking about emergency catch alls, don't they have enough to do already?

Concentrating responsibility

  • Concentrating all responsibility on social issues on a single point creates a scapegoat: we're blamed for any conduct issue, and we're blamed for any action we take on conduct issues
    • also, when you are a small group you are personally identified with it. Taking action on a person may mean making a new enemy, and becoming a target for harassment, retaliation, or even just the general unwarranted hostility of someone who is left with an axe to grind
  • As long as responsibility is centralised, any action one takes as a response of one micro-aggression (or one micro-aggression too many) is an overreaction. Distributing that responsibility allows a finer granularity of actions to be taken
    • you don't call the police to tell someone they're being annoying at the pub: the people at the pub will tell you you're being annoying, and the police is called if you want to beat them up in response
  • We are also a community where we have no tool to give feedback to posts, so it still looks good to nitpick stupid details with smart-looking tranchant one-liners, or elaborate confrontational put-downs, and one doesn't get the feedback of "that did not help". Compare with discussing https://salsa.debian.org/debian/grow-your-ideas/ which does have this kind of feedback
    • the lack of moderation and enforcement makes the Debian community ideal for easy baiting, concern trolling, dog whistling, and related fun, and people not empowered can be so manipulated to troll those responsible
    • if you're fragile in Debian, people will play cat and mouse with you. It might be social awkwardness, or people taking themselves too serious, but it can easily become bullying, and with no feedback it's hard to tell and course correct
  • Since DAM and DPL are where the ball stops, everyone else in Debian can afford to let the ball drop.
  • More generally, if only one group is responsible, nobody else is

Empowering developers

  • Police alone does not make a community safe: a community makes a community safe.
  • DDs currently have no power to act besides complaining to DAM, or complaining to Community Team that then can only pass complaints on to DAM.
    • you could act directly, but currently nobody has your back if the (micro-)aggression then starts extending to you, too
  • From no power comes no responsibility. And yet, the safety of a community is sustainable only if it is the responsibility of every member of the community.
  • don't wait for DAM as the only group who can do something
  • people should be able to address issues in smaller groups, without escalation at project level
  • but people don't have the tools for that
  • I/we've shouldered this responsibility for far too long because nobody else was doing it, and it's time the whole Debian community gets its act together and picks up this responsibility as they should be. You don't get to not care just because there's a small number of people who is caring for you.

What needs to happen

  • distinguish DAM decisions from decisions that are more about vision and direction, and would require more representation
  • DAM warnings shouldn't belong in DAM
  • who is responsible for interpretation of the CoC?
  • deciding what to do about controversial people shouldn't belong in DAM
  • curation of the community shouldn't belong in DAM
  • can't do this via GRs, it's a mess to do a GR to decide how acceptable is a specific person's behaviour, and a lot of this requires more and more frequent micro-decisions than one'd do via GRs
pdo debian eng talk

Doing things /together/

Here are the slides of mine and Ulrike's talk Doing things /together/.

Our thoughts about cooperation aspects of doing things together.

Sometimes in Debian we do work together with others, and sometimes we are a number of people who work alone, and happen to all upload their work in the same place.

In times when we have needed to take important decisions together, this distinction has become crucial, and some of us might have found that we were not as good at cooperation as we would have thought.

This talk is intended for everyone who is part of a larger community. We will show concepts and tools that we think could help understand and shape cooperation.

Video of the talk:

The slides have extensive notes: you can use View → Notes in LibreOffice Impress to see them.

Here are the Inkscape sources for the graphs:

Here are links to resources quoted in the talk:

In the Q&A, pollo asked:

How can we still have a good code review process without making it a "you need to be perfect" scenario? I often find picky code reviews help me write better code.

Ulrike wrote a more detailed answer: Code reviews: from nitpicking to cooperation

pdo debian eng talk

Multiple people

These are the notes from my DebConf18 talk

Slides are available in pdf and odp.

Abtract:

Starting from Debian, I have been for a long time part of various groups where diversity is accepted and valued, and it has been an invaluable supply of inspiration, allowing my identity to grow with unexpected freedom.

During the last year, I have been thinking passionately about things such as diversity, gender identity, sexual orientation, neurodiversity, and preserving identity in a group.

I would like to share some of those thoughts, and some of that passion.

Multiple people

"Debian is a relationship between multiple people", it (I) says at the entrance.

I grew up in a small town, being different was not allowed. Difference attracted "education", well-meaning concern, bullying.

Everyone knew everyone, there was no escape to a more fitting bubble, there was very little choice of bubbles.

I had to learn from a very young age the skill of making myself accepted by my group of peers.

It was an essential survival strategy.

Not being a part of the one group meant becoming a dangerous way of defining the identity of the group: "we are not like him". And one would face the consequences.

"Debian is a relationship between multiple people", it (I) says at the entrance.

Debian was one of the first opportunities for me to directly experience that.

Where I could begin to exist

Where I could experience the value and pleasure of diversity.

Including mine.

I am extremely grateful for that.

I love that.

This talk is also a big thank you to you all for that.

"Debian is a relationship between multiple people", it (I) says at the entrance.

Multiple people does not mean being all the same kind of person, all doing all the same kind of things.

Each of us is a different individual, each of us brings their unique creativity to Debian.

Classifying people

How would you describe a person?

There are binary definitions:

  • Good / Bad
  • Smart / Stupid
  • Pretty / Ugly
  • White / Not white
  • Rich / Poor
  • From here / immigrant
  • Not nerd / Nerd
  • Straight / Gay
  • Cis / Trans
  • Polite / Impolite
  • Right handed / left handed (some kids are still being "corrected" for being left handed in Italy)
  • Like me / unlike me

Labels: (like package sections)

  • Straight
  • Gay
  • Bi
  • Cis
  • Trans
  • Caucasian
  • ...
  • Like me / unlike me

Spectra: (like debtags)

  • The gender spectrum
  • The sexual preference spectrum
  • The romantic preference spectrum
  • The neurodiversity spectrum
  • The skin color spectrum
  • The sexual attraction spectrum

We classify packages better than we classify people.

Identity / spectrums

I'm going to show a few examples of spectra; I chose them not because they are more or less important than others, but because they have recently been particularly relevant to me, and it's easier for me to talk about them.

If you wonder where you are in each spectrum, know that every place is ok.

Think about who you are, not about who you should be.

Gender identity

My non binary awareness began with d-w and gender neutral documentation.

Sexual orientation

https://en.wikipedia.org/wiki/Human_sexuality_spectrum

Neurodiversity

I'll introduce neurodiversity by introducing allism

An allistic person learns subconsciously that ey is dependent on others for eir emotional experience. Consequently, ey tends to develop the habit of manipulating the form and content of social interactions in order to elicit from others expressions of emotion that ey will find pleasing when incorporated into eir mind.

https://fysh.org/~zefram/allism/allism_intro.txt

The more I reason about this (and I reasoned about this a lot, before, during and after therapy), the more I consider it a very rational adaptation, derived from a very clear message I received since I was a small child: nobody cared whom I was, and to be accepted socially I needed to act a social part, which changed from group to group. Therefore, socially, I was wrong, and I had to work to deserve the right to exist.

What one usually sees of me in large groups or when out of comfort zone, is a social mask of me.

This paper is also interesting: analyzing tweets of people and their social circle, they got to the point of being able to predict what a person will write by running statistics only on what their friends are writing.

Is it measuring identity or social conformance?

Discussion about the autism spectrum tends to get very medical very fast, and the DSM gets often criticised for a tendency of turning diversity into mental health issues.

I stick to my experience from a different end of the spectrum, and there are various resources online to explore if you are interested in more.

Other spectra

I hope you get the idea about spectrum and identity.

There are many more, those were at the top of my head because of my recent experiences.

Skin color, age, wealth, disability, language proficiency, ...

How to deal with diversity

How to deal with my diversity

Let's all assume for a moment that each and every single one of us is ok.

I am ok.

You are ok.

You've been ok since the moment you were born.

Being born is all you need to deserve to exist.

You are ok, and you will always be ok.

Like every single person alive.

I'm ok.

You're ok.

We're all ok.

Hold on to that thought for the next 5 minutes. Hold onto it for the rest of your life.

Ok. A lot of problems are now solved. A lot of energy is not wasted anymore. What next?

Get to know myself

Awareness:

  • what do I like / what don't I like?
  • what am I interested in?
  • what would I like to do?
  • what do I know? What would I like to know?
  • what do I feel?
  • what do I need?

Get in touch with my feelings, get to know my needs.

Here's a simple algorithm to get to know your feelings and needs:

  1. If you are happy, take this phrase: I feel … because my need of … is being met
  2. If you are not happy, take this phrase: I feel … because my need of … is not being met
  3. Fill the first space with one of the words from here
  4. Fill the second space with one of the words from here
  5. Done!

To know more about Non-Violent Communication, I suggest this video

This other video I also liked.

Forget absolute truths, center on my own experience. Have a look here for more details.

Learn to communicate and express myself

Communicating/being oneself

  • enjoy what I like
  • pursue my interests
  • do what I want to do
  • study and practice what I'm interested in
  • let myself be known and seen by those who respect who I am

Find out where to be myself

Look for safe spaces where I can activate parts of myself

  • Friends
  • Partners (but not just partners)
  • Interest groups
  • Courses / classes
  • Debian
  • DebConf!

Learn to protect myself

I will make mistakes acting as myself:

  • Mistakes do not invalidate me, Mistakes are opportunity for learning.
  • I need to make a distinction between "I did something wrong" and "I am wrong"

Learn to know my boundaries

Learn to recognise when they are being crossed

Negotiate

Use my anger to protect my integrity. I do not need to hurt others to protect myself

How to deal with the diversity of others

Diversity is a good thing

Once I realised I can be ok in my diversity, it was easier to appreciate the diversity of others

Opening to others doesn't need to sacrifice oneself.

  • I can embrace my own identity without denying the identity of others.
  • Affirming me does not imply destroying you
  • If I feel I'm right, it doesn't mean that you are wrong

Curiosity is a good default.

Do not assume. Assume better and I'll be disappointed. Assume worse and I'll miss good interactions

  • Listen
  • Connect, don't be creepy
  • Interact with people, not things
  • People are unique like me
  • Respect others and myself
  • listen to my red flags
  • choose my involvement
  • choose again

When facing the new and unsettling, use curiosity if I have the energy, or be aware that I don't, and take a step back

The goal of the game is to affirm all identities, especially oneself.

Love freely.

Expect nothing.

Liberate myself from imagined expectations.

YKINMKBYKIOK.

What is not acceptable

https://en.wikipedia.org/wiki/Paradox_of_tolerance

The paradox of tolerance, as a comic strip

Less well known is the paradox of tolerance: Unlimited tolerance must lead to the disappearance of tolerance. If we extend unlimited tolerance even to those who are intolerant, if we are not prepared to defend a tolerant society against the onslaught of the intolerant, then the tolerant will be destroyed, and tolerance with them. — In this formulation, I do not imply, for instance, that we should always suppress the utterance of intolerant philosophies; as long as we can counter them by rational argument and keep them in check by public opinion, suppression would certainly be unwise. But we should claim the right to suppress them if necessary even by force; for it may easily turn out that they are not prepared to meet us on the level of rational argument, but begin by denouncing all argument; they may forbid their followers to listen to rational argument, because it is deceptive, and teach them to answer arguments by the use of their fists or pistols. We should therefore claim, in the name of tolerance, the right not to tolerate the intolerant.

Use diversity for growth

Identifying where I am gives me more awareness about myself.

Identifying where I am shows me steps I might be interested in making.

Identity can change, evolve, move I like the idea of talking about my identity in the past tense

Diversity as empowerment, spectrum as empowerment

  • I'm in the trans* spectrum at least as far as not needing to follow gender expectations, possibly more
  • I'm in the autism spectrum at least as far as not needing to follow social expectations, possibly more
  • I'm in the asexual spectrum at least as far as not seeing people as sexual objects, possibly more Once I'm in, I'm free to move, I can reason on myself, see other possibilities

Take control of your narrative: what is your narrative? Do you like it? Does it tell you now what you're going to like next year, or in 5 years? Is it a problem if it does?

Conceptual space is not limited. Allocating mental space for new diversity doesn't reduce one's own mental space, but it expands it

Is someone trying to control your narrative? gaslighting, negging, patronising.

Debian and diversity

Impostor syndrome

Entering a new group: impostor syndrome. Am I good enough for this group?

Expectations, perceived expectations, perceived changes in perceived identity, perceived requirements on identity

I worked some months with a therapist to deal with that, to, it turned out, learn to give up the need to work to belong.

In the end, it was all there in the Diversity Statement:

No matter how I identify myself or how others perceive me: I am welcome, as long as I interact constructively with my community.

Ability of the group to grow, evolve, change, adapt, create

And here, according to Trout, was the reason human beings could not reject ideas because they were bad: “Ideas on Earth were badges of friendship or enmity. Their content did not matter. Friends agreed with friends, in order to express friendliness. Enemies disagreed with enemies, in order to express enmity.

“The ideas Earthlings held didn’t matter for hundreds of thousands of years, since they couldn’t do much about them anyway. Ideas might as well be badges as anything.

(Kurt Vonnegut, "Breakfast of Champions", 1973)

Keep one's identity in Debian

If your identity is your identity, and the group changes, it actually extends, because you keep being who you are.

If your identity is a function of the group identity, you become a control freak for where the group is going.

When people define their identity in terms of belonging to a group, that group cannot change anymore, because if it does, it faces resistance from its members, that will see their own perceived identity under threat.

The threat is that rituals, or practices, that validated my existance, that previously used to work, cease to function. systemd?

  • can I adapt when facing something new and unexpected?
  • do I have the energy to do it?
  • do I allow myself to ask for help?

Free software

Us, and our users, we are a diverse ecosystem

Free Software is a diverse ecosystem

Free software can be a spectrum (free hardware, free firmware, free software, free javascript in browsers...)

Vision

Debian exists, and can move in a diverse and constantly changing upstream ecosystem

Vision / non limiting the future of Debian (if your narrative tells you what you're going to like next year, you might have a problem) (but before next year I'd like to get to a point that I can cope with X)

Debian doesn't need to be what people need to define their own identity, but it is defined by the relationship between different, diverse, evolving people

Appreciate diversity, because there's always something you don't know / don't understand, and more in the future.

Nobody can know all of Debian now, and in the future, if we're successful, we're going to get even bigger and more complex.

We're technically complex and diverse, we're socially complex and diverse. We got to learn to deal with that.

Because we're awesome. We got to learn to deal with with that.

Ode to the diversity statement

https://www.debian.org/intro/diversity

debian life pdo eng talk

Consensually doing things together?

On 2017-08-06 I have a talk at DebConf17 in Montreal titled "Consensually doing things together?" (video). Here are the talk notes.

Abstract

At DebConf Heidelberg I talked about how Free Software has a lot to do about consensually doing things together. Is that always true, at least in Debian?

I’d like to explore what motivates one to start a project and what motivates one to keep maintaining it. What are the energy levels required to manage bits of Debian as the project keeps growing. How easy it is to say no. Whether we have roles in Debian that require irreplaceable heroes to keep them going. What could be done to make life easier for heroes, easy enough that mere mortals can help, or take their place.

Unhappy is the community that needs heroes, and unhappy is the community that needs martyrs.

I’d like to try and make sure that now, or in the very near future, Debian is not such an unhappy community.

Consensually doing things together

I gave a talk in Heidelberg.

Valhalla made stickers

Debian France distributed many of them.

There's one on my laptop.

Which reminds me of what we ought to be doing.

Of what we have a chance to do, if we play our cards right.

I'm going to talk about relationships. Consensual relationships.

Relationships in short.

Nonconsensual relationships are usually called abuse.

I like to see Debian as a relationship between multiple people.

And I'd like it to be a consensual one.

I'd like it not to be abuse.

Consent

From wikpedia:

In Canada "consent means…the voluntary agreement of the complainant to engage in sexual activity" without abuse or exploitation of "trust, power or authority", coercion or threats.[7] Consent can also be revoked at any moment.[8]»

There are 3 pillars often included in the description of sexual consent, or "the way we let others know what we're up for, be it a good-night kiss or the moments leading up to sex."

They are:

  • Knowing exactly what and how much I'm agreeing to
  • Expressing my intent to participate
  • Deciding freely and voluntarily to participate[20]

Saying "I've decided I won't do laundry anymore" when the other partner is tired, or busy doing things.

Is different than saying "I've decided I won't do laundry anymore" when the other partner has a chance to say "why? tell me more" and take part in negotiation.

Resources:

Relationships

Debian is the Universal Operating System.

Debian is made and maintained by people.

The long term health of debian is a consequence of the long term health of the relationship between Debian contributors.

Debian doesn't need to be technically perfect, it needs to be socially healthy.

Technical problems can be fixed by a healty community.

The Thomas-Kilmann Conflict Mode Instrument: source png.

Motivations

Quick poll:

  • how many of you do things in Debian because you want to?
  • how many of you do things in Debian because you have to?
  • how many of you do both?

What are your motivations to be in a relationship?

Which of those motivations are healthy/unhealthy?

  • healthy sustain the relationship
  • unhealthy may explode spectacularly at some point

"Galadriel" (noun, by Francesca Ciceri): a task you have to do otherwise Sauron takes over Middle Earth

See: http://blog.zouish.org/nonupdd/#/22/1

What motivates me to start a project or pick one up?

  • I have an idea for for something fun or useful
  • I see something broken and I have an idea how to fix it

What motivates me to keep maintaning a project?

  • Nobody else can do it
  • Nobody else can be trusted to do it
  • Nobody else who can and can be trusted to do it is doing it
  • Somebody is paying me to do it

What motivates you?

What's an example of a sustainable motivation?

  • it takes me little time?
  • it's useful for me
  • It's fun
  • It saves me time to keep something running that if it breaks when I or somebody else needs it
  • it makes me feel useful? (then if I stop, I become useless, then I can't afford to stop?)
  • Getting positive feedback (more "you're good" than "i use it") ?

Is it really all consensual in Debian?

  • what tasks are done by people motivated by guilt / motivated by Galadriel?
  • if I volunteer to help team X that is in trouble, will I get stuck doing all the work as soon as people realise things move fine again and finally feel free to step back?

Energy

Energy that thing which is measured in spoons. The metaphore comes from people suffering with chronic health issues:

"Spoons" are a visual representation used as a unit of measure used to quantify how much energy a person has throughout a given day. Each activity requires a given number of spoons, which will only be replaced as the person "recharges" through rest. A person who runs out of spoons has no choice but to rest until their spoons are replenished.

For example, in Debian, I could spend:

  • Routine task: 1 spoon
  • Context switch: 2 spoons
  • New corner case: 5 spoons
  • Well written bug report: -1 spoon
  • Interesting thread: -1 spoon
  • New flamewar: 3 spoons

What is one person capable of doing?

  • are the things that we expect a person to do the things that one person can do?
  • having a history of people who can do it anyway is no excuse: show compassion to those people, take some of their work, thank them, but don't glorify them

Have reasonable expectations, on others:

  • If someone is out of spoons, they're out of spoons; they don't get more spoons if you insist; if you insist, you probably take even more spoons from them
  • If someone needs their spoons for something else, they are entitled to
  • If someone gets out of spoons for something important, and nobody else can do it, it's not their fault but a shared responsibility

Have reasonable expectations, on yourself:

  • If you are out of spoons, you are out of spoons
  • If you need spoons for something else, use them for something else
  • If you are out of spoons for something important, and nobody else can do it, it's not your problem, it's a problem in the community

Debian is a shared responsibility

  • Don't expect few people to take care of everything
  • Leave space for more people to take responsibility for things
  • Turnover empowers
  • Humans are a renewable resource, but only if you think of them that way

When spoons are limited, what takes more energy tends not to get done

  • routine is ok
  • non-routine tends to get stuck in the mailbox waiting for a day with more free time
    • are we able to listen when tricky cases happen?
    • are we able to respond when tricky cases happen?
    • are we able to listen/respond when socially tricky cases happen?
    • are we able to listen/respond when harassment happens?
    • can we tell people raising valid issues from troublemakers?
  • in NM
    • it's easier to accept a new maintainer than to reject them
    • it's hard or impossible to make a call on a controversial candidate when one doesn't know that side of Debian
  • I'm tired, why you report a bug? I don't want to deal with your bug. Maybe you are wrong and your bug is invalid? It would be good if you were wrong and your bug was invalid.
  • even politeness goes when out of spoons because it's too much effort

As the project grows, project-wide tasks become harder

Are they still humanly achievable?

  • release team
  • DAM (amount of energy to deal with when things go wrong; only dealing with when things go spectacularly wrong?)
  • DPL (how many people candidate to this year elections?)

I don't want Debian to have positions that require hero-types to fill them

  • heroes are rare
  • heroes are hard to replace
  • heroes burn out
  • heroes can become martyrs
  • heroes can become villains
  • heroes tend to be accidents waiting to happen

Dictatorship of who has more spoons:

  • Someone who has a lot of energy can take more and more tasks out of people who have less, and slowly drive all the others away
  • Good for results, bad for the team
  • Then we have another person who is too big to fail, and another accident waiting to happen

Perfectionism

You are in a relationship that is just perfect. All your friends look up to you. You give people relationship advice. You are safe in knowing that You Are Doing It Right.

Then one day you have an argument in public.

You don't just have to deal with the argument, but also with your reputation and self-perception shattering.

One things I hate about Debian: consistent technical excellence.

I don't want to be required to always be right.

One of my favourite moments in the history of Debian is the openssl bug

Debian doesn't need to be technically perfect, it needs to be socially healthy, technical problems can be fixed.

I want to remove perfectionism from Debian: if we discover we've been wrong all the time in something important, it's not the end of Debian, it's the beginning of an improved Debian.

Too good to be true

There comes a point in most people's dating experience where one learns that when some things feel too good to be true, they might indeed be.

There are people who cannot say no:

  • you think everything is fine, and you discover they've been suffering all the time and you never had a clue

There are people who cannot take a no:

  • They depend on a constant supply of achievement or admiration to have a sense of worth, therefore have a lot of spoons to invest into getting it
  • However, when something they do is challenged, such as by pointing out a mistake one has made, or a problem with their behaviour, all hell breaks loose, beacuse they see their whole sense of worth challenged, too

Note the diversity statement: it's not a problem to have one of those (and many other) tendencies, as long as one manages to keep interacting constructively with the rest of the community

Also, it is important to be aware of these patterns, to be able to compensate for one's own tendencies. What happens when an avoidant person meets a narcissistic person, and they are both unaware of the risks?

Resources:

Note: there are problems with the way these resources are framed:

  • These topics are often very medicalised, and targeted at people who are victims of abuse and domestic violence.
  • I find them useful to develop regular expressions for pattern matching of behaviours, and I consider them dangerous if they are used for pattern matching of people.

Red flag / green flag

http://pervocracy.blogspot.ca/2012/07/green-flags.html

Ask for examples of red/green flags in Debian.

Green flags:

  • you heard someone say no
  • you had an argument with someone and the outcome was positive for both

Red flags:

  • you feel demeaned
  • you feel invalidated

Apologies / Dealing with issues

I don't see the usefulness of apologies that are about accepting blame, or making a person stop complaining.

I see apologies as opportunities to understand the problem I caused, help fix it, and possibly find ways of avoiding causing that problem again in the future.

A Better Way to Say Sorry lists a 4 step process, which is basically what we do when in bug reports already:

1, Try to understand and reproduce the exact problem the person had. 2. Try to find the cause of the issue. 3. Try to find a solution for the issue. 4. Verify with the reporter that the solution does indeed fix the issue.

This is just to say

My software ate
the files
that where in
your home directory

and which
you were probably
needing
for work

Forgive me
it was so quick to write
without tests
and it worked so well for me

(inspired by a 1934 poem by William Carlos Williams)

Don't be afraid to fail

Don't be afraid to fail or drop the ball.

I think that anything that has a label attached of "if you don't do it, nobody will", shouldn't fall on anybody's shoulders and should be shared no matter what.

Shared or dropped.

Share the responsibility for a healthy relationship

Don't expect that the more experienced mates will take care of everything.

In a project with active people counted by the thousand, it's unlikely that harassment isn't happening. Is anyone writing anti-harassment? Do we have stats? Is having an email address and a CoC giving us a false sense of security?

When you get involved in a new community, such as Debian, find out early where, if that happens, you can find support, understanding, and help to make it stop.

If you cannot find any, or if the only thing you can find is people who say "it never happens here", consider whether you really want to be in that community.

(from http://www.enricozini.org/blog/2016/debian/you-ll-thank-me-later/)

There are some nice people in the world. I mean nice people, the sort I couldn’t describe myself as. People who are friends with everyone, who are somehow never involved in any argument, who seem content to spend their time drawing pictures of bumblebees on flowers that make everyone happy.

Those people are great to have around. You want to hold onto them as much as you can.

But people only have so much tolerance for jerkiness, and really nice people often have less tolerance than the rest of us.

The trouble with not ejecting a jerk — whether their shenanigans are deliberate or incidental — is that you allow the average jerkiness of the community to rise slightly. The higher it goes, the more likely it is that those really nice people will come around less often, or stop coming around at all. That, in turn, makes the average jerkiness rise even more, which teaches the original jerk that their behavior is acceptable and makes your community more appealing to other jerks. Meanwhile, more people at the nice end of the scale are drifting away.

(from https://eev.ee/blog/2016/07/22/on-a-technicality/)

Give people freedom

If someone tries something in Debian, try to acknowledge and accept their work.

You can give feedback on what they are doing, and try not to stand in their way, unless what they are doing is actually hurting you. In that case, try to collaborate, so that you all can get what you need.

It's ok if you don't like everything that they are doing.

I personally don't care if people tell me I'm good when I do something, I perceive it a bit like "good boy" or "good dog". I rather prefer if people show an interest, say "that looks useful" or "how does it work?" or "what do you need to deploy this?"

Acknowledge that I've done something. I don't care if it's especially liked, give me the freedom to keep doing it.

Don't give me rewards, give me space and dignity.

Rather than feeding my ego, feed by freedom, and feed my possibility to create.

pdo debian life eng talk

My semi serious stand up comedy notes

Video

Disclaimers

“Someone has said that it requires less mental effort to condemn than to think.”

(Emma Goldman, on several things including mailing list flamewars)

Fascinating Aïda's "Dogging" song.

Look for "dogging etiquette" for more examples of code of conducts. Just don't take your computer for repair immediately afterwards™.

Introduction

Every daring attempt to make a great change in existing conditions, every lofty vision of new possibilities for the human race, has been labeled Utopian.

(Emma Goldman, on the Debian Social Contract)

I am going to talk about many topics that we all know have so much in common:

  • Anarchism
  • Poliamory
  • BDSM
  • and Free Software

They are all, after all:

  • People
  • Consensually
  • Doing Things
  • Together

BDSM

A person is no less a slave because they are allowed to choose a new master once in a term of years.

(Lysander Spooner about proprietary cloud service providers)

If you thought you've seen it all with recursive acronyms, here's a chain acronym: Bondage Discipline, Dominance Submission, Sado Masochism.

Why I think BDSM is interesting: not (just) because of whips, but for having a lot of awareness about power releationships. Why should one accept from a coworker a level of abuse that would be considered a hard limit when negotiating with a trusted dom?

The BDSM Free Software definition: "I refuse to be bound by software I cannot negotiate with".

YKINMKBYKIOK (Your Kink Is Not My Kink But Your Kink Is Okay) is a nice example of dealing with diversity, and it also definitely solves the emacs vs vi debate.

Comfort zones, safewords, traffic light flow control, safety.

"No means no", unless there has been a long discussion first, and a safeword is in place, in which case "Fuzzy purple unicorn" means "no"

"No means no", and if someone insists after a "no", it becomes harassment.

"No means no" is a precondition for being able to say "yes": http://pervocracy.blogspot.de/2011/03/no-and-no-and-no-and-yes.html

Aftercare! Aftercare! Release parties! High fives! Solidarity after flamewars or votes!

Poliamory

If love does not know how to give and take without restrictions, it is not love, but a transaction that never fails to lay stress on a plus and a minus.

(Emma Goldman, on volunteer projects)

Polyamory is the practice, desire, or acceptance of intimate relationships that are not exclusive with respect to other sexual or intimate relationships, with knowledge and consent of everyone involved.

Compersion, n: the feeling you get when someone else also takes good care of one of your packages.

We currently allow only one value in the Maintainer field: takeover is traumatic, because values can only be replaced if values could be added instead, and removed when they don't make sense anymore...

What is your definition of love? My current one is: my world is better with you in it.

Relationship anarchy is the practice of forming relationships which are not bound by rules aside from what the people involved mutually agree on. How do you call a relationship that is bound by rules that the people involved do not agree on?

From discussions after the talk

New Relationship Energy, the excitement when you start to maintain a new package, and the risk of been carried away by the excitement and neglecting all the other ones.

Consent

Anarchism, to me, means not only the denial of authority, not only a new economy, but a revision of the principles of morality. It means the development of the individual as well as the assertion of the individual. It means self-responsibility, and not leader worship.

(Voltairine de Cleyre about trusting lintian warnings)

You need to know what you are doing, and what situation you're putting yourself into.

You need to know that the person asking a question really is able to accept any answer, and take it seriously.

You need to feel that you have alternatives.

Be selfish when you ask, honest when you reply, and when others reply, take them seriously. If any of this doesn't stand, I find it hard to trust that we are in a consensual situation.

When is one supposed to learn about consent?

  • I see little consensuality in standard education.
  • I see little consensuality at work.

Consent explained with tea.

Practical advice

Anarchism has but one infallible, unchangeable motto, ‘Freedom.’ Freedom to discover any truth, freedom to develop, to live naturally and fully.

(Lucy Parsons about the DFSG)

Relationship advice and work advice have a lot in common:

Relationship advice from 99 ways to ruin an open source project

Online participation advice from How to Screw Up Your Relationship (and make everyone miserable while you’re at it)

Packaging advice from BDSM Basics: 20 Unsolicited Tips for New Dominants

Advice about joining a new community from Advice to a newbie submissive about dominants

♥ ♥ ♥

Dear Debian, and dear everyone contributing to it: my world is better with you in it.

I love you all :* <3

debian eng life talk pdo

Debian Contributors - Un nuovo prestigioso titolo di cui fregiarsi con gli amici

Held on 2013-10-27 at Erlug LinuxDay in Bologna, Italy.

Resources:

talk pub ita

Debian Contributors - A revolution in Debian project headwear fashion

Held on 2013-08-16 at DebConf in Vaumarcus, Switzerland.

Resources:

talk pub eng

Nobody expects Debian Contributors!

Held on 2013-08-11 at DebConf in Vaumarcus, Switzerland.

Pre-BOF notes

The problem

People seem to identify official recognition with some kind of label. In that sense, you only get official recognition from Debian if you are DM or DD.

I'd like to offer some form of official recognition to non-DDs who are not DM. That can be because they do work other than packaging, or because their packaging work doesn't require DM rights (for example, they may be members of teams that work similarly to the Perl one, or people doing a lot of sponsored NMUs).

I wish this sort of official recognition can also mean that DM can be just a technical mean to a technical end, and loses the "official hat" meaning, so that people don't try to get DM too early, and developers don't advocate people for DM just to give them some kind of recognition.

The proposal

We had this idea before:

  1. Create a new label, purely for recognition purposes. Let's say "Debian Contributor".
  2. Define something you get for having that label.

But here are some novel implementation details that might just make it work:

  1. Give that label to "anyone who has recently done work for Debian.
  2. What you get for having that label, is to have your name on a list!

Rationale and details

Now, for recognition, you don't need much more than to have your name on some official list of Debian Contributors. We can list "Current Debian Contributors" and move names to "Past Debian Contributors" if there has been no activity for some time, so that we don't lose credits.

I'd like each name on the list to point to a page which lists the person's contributions, too, so that each person's contribution is credited properly, and we would also have a useful page for NM.

The beauty of the proposal is that the procedure for assigning the label is fully automated, hooking into whatever infrastructure we have to track contributions. That means it's fair, it's low-maintenance, and that to get on the list you just need to Get Some Work Done. Do-ocracy, for labels, too.

Now, unfortunately we don't have infrastructure in place to track all kind of contributions: see more-diversity-in-skills. But that lack of infrastructure does not need to be a blocker.

We can see it the other way round: if a team's contributors don't automatically show up on the list, that is a strong motivating factor for that team to come up with a way to acknowledge their contributors.

This means that by defining our official recognition label in this way, we also create a reason for teams to actually credit their own work properly. This is twisted and evil, and I am proud of it.

Practical/technical issues

This can be something we do at DebConf.

For naming, we can ask each Debian contributor to get an Alioth account, and use it as a handle to refer to the person. That gives us a uniform namespace.

To track work, we need a mapping between Alioth accounts and GPG keys and email addresses. That is something good to have anyway.

TODO: check w/ Lo-lan-do how alioth can keep a list of gpg key id associated to accounts, similarly to what it already does for ssh keys.

Notes taken during DebConf and the BOF

We can also choose not to require people to have an Alioth account and implement our own way of managing which identifiers (login, fingerprint, email, wikinames...) belong to a same person. It is good to give people a choice about their visible identity in Debian.

Some data sources may define 'contributor' status; some data sources extend contributor begin/end times (like mailing lists) as soon as one is a contributor through other things. For example, the Press Team could maintain a static file with a list of member email addresses, and then the press team mailing list archives can be used to see when one has started and ended contributing.

Some lists are populated by real contributors, for example for teams that have a workflow based on subject tags in mailing list posts. Those can be used to define membership and not only timeframe info: it's up to a team to decide.

One needs to be able to opt out, or control which kinds of contributions are made visible.

Email address should not be published by default. One can choose to publish their email address, and/or a description string (for example, to tell the two "Luca Bruno"s apart, and optionally a short bio.

Is it legal? We can make it opt-in by not publishing data by default, and instead mailing people saying «We noticed that you have started contributing to Debian, and we would like to thank you for it. Please click here if you would like to appear in the Debian Contributors page.»

Also, we should not force people to be thanked. People should have a way to control which kind of contributions are made visible, or to remove themselves from the list entirely.

We do not need to look for perfection: if a person isn't credited and can get credited by contributing some more, that's fine. However, if one has done a lot of work already, they should be credited.

Also, coarse granularity is ok. Time resolution could be "a month". It is ok if credits appear/update a day or two after a contribution has been made. Is it ok not to list details of every contribution: I'm just happy with saying "active in the BTS from 2003 to 2013" and link to DDPO.

General rule of thumb: «I'm happy to thank you, but I shouldn't need to go out of my way to do so».

talk pub eng
Archive of all posts
Archive
Top 15 tags
eng 652 pdo 548 debian 323 sw 235 tips 123 rant 79 life 76 links 74 talk 67 ita 64 songs 61 pub 60 cazzeggio 53 debtags 50 python 35
Recent series