Latest posts for tag talk
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.
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
- 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
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
- 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)
- 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
- 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
- We have the Diversity Statement
- We have the Code of Conduct
- We have the DebConf Code of Conduct
- We have the Debian Mailinglist Code of Conduct
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: 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
- example: gender, minority groups, affirmative action, inclusion, anything about the community team itself, anything about the CoC, systemd, usrmerge, dam warnings, expulsions
- 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 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
- 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
- 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
- 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
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:
- Carlo M. Cipolla - Wikipedia
- Thomas–Kilmann Conflict Mode Instrument - Wikipedia
- The Evolution of Trust
- Moral behavior in animals
- Taibi Kahler - Wikipedia
- Kahler's Drivers questionnaire / Antreiber Test - English and German
- Alison Green Coaching - Behavioural Drivers Questionnaire
- Founder's syndrome - Wikipedia
- Peter principle - Wikipedia
- Benevolent dictator for life - Wikipedia
- Difficult Conversations: How to Discuss What Matters Most
- Getting to Yes - Wikipedia
- Webcomics - Pepper&Carrot
In the Q&A,
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
These are the notes from my DebConf18 talk
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.
"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.
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.
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)
- 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.
My non binary awareness began with d-w and gender neutral documentation.
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.
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.
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.
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
- 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:
- If you are happy, take this phrase: I feel … because my need of … is being met
- If you are not happy, take this phrase: I feel … because my need of … is not being met
- Fill the first space with one of the words from here
- Fill the second space with one of the words from here
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
- 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
- Partners (but not just partners)
- Interest groups
- Courses / classes
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
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
- 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.
Liberate myself from imagined expectations.
What is not acceptable
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
Debian and diversity
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?
Us, and our users, we are a diverse ecosystem
Free Software is a diverse ecosystem
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
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.
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.
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. Consent can also be revoked at any moment.»
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."
- Knowing exactly what and how much I'm agreeing to
- Expressing my intent to participate
- Deciding freely and voluntarily to participate
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.
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.
- 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
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 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
- 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
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?
- Examples of abuse patterns (trigger warning: judgemental)
- Wikipedia on narcissist personality, supply, injury and rage (trigger warning: medical)
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
Ask for examples of red/green flags in Debian.
- you heard someone say no
- you had an argument with someone and the outcome was positive for both
- 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
that where in
your home directory
you were probably
it was so quick to write
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.
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.
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.
“Someone has said that it requires less mental effort to condemn than to think.”
(Emma Goldman, on several things including mailing list flamewars)
Look for "dogging etiquette" for more examples of code of conducts. Just don't take your computer for repair immediately afterwards™.
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:
- and Free Software
They are all, after all:
- Doing Things
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", 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!
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.
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.
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:
- Sick systems: How to keep someone with you forever
- What technical recruiters can learn from online dating
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
Held on 2013-08-11 at DebConf in Vaumarcus, Switzerland.
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.
We had this idea before:
- Create a new label, purely for recognition purposes. Let's say "Debian Contributor".
- Define something you get for having that label.
But here are some novel implementation details that might just make it work:
- Give that label to "anyone who has recently done work for Debian.
- 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.
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».