Katheryn Sutter

I'll be discussing what codes of conduct are intended to protect. No code will be appropriate in all contexts; free software projects' needs and cultures differ enough so that no single code of conduct can cover them all. Groups need to establish their own codes, according to their needs and current culture.

Before arguing what codes of conduct should say, how they should be implemented, and who should enforce them, we need to consider what these codes might protect and why. Then, in the future, any given group might think better about criteria for proposed communication guidelines or codes of conduct.

Facilitated discussion and short story sharing. What works well in some teams? How to share that knowledge across teams? How have new contributors become good project leaders? Where have good moderators learned their skills? How should we discuss team problems in ways that lead to good outcomes? In the future, how might Debian encourage discussion-process skills between teams?

On the surface, this story shares vignettes about my Mom. But its purpose is to increase awareness of human resources in technology, and overlooked career pathways of women and other young technologists. For example, In 1973 RCA hired her for self-directed projects in their chip prototyping lab. A marathon week of late-night needlework produced a crochet blanket and proved her mathematical mind to skeptical women co-workers. She told me stories of such ladies who wrapped wires for NASA a few years before. She said women's milleniums of technical fiber-crafts were acknowledged when they helped put men on the moon.

Collaborative software-development groups face dual demands in technical debates: analyzing participant-concerns rationally, while keeping organizational cultures healthy. Codes of conduct help, but some argue that being nice is antithetical to critical intelligence, just as group intelligence may be lost when feelings run strong, or when minority perspectives are bullied into silence. Sometimes social issues do not matter in technical debates, and sometimes they do. This talk introduces specific methods of getting beyond 'objectivity versus subjectivity' and 'facts versus values' conflicts in technical-policy discussions. The presentation will suggest learning to hear conflicts like a facilitator, noticing technical debates that do not hinge on social issues at their core. We will identify those factual types of debates and how validating their solutions differ from other conflicts, and how to tease out the differences. The first step is about learning and recognition. Suggestions offered here are based on the Theory of Communicative Rationality, of Jurgen Habermas. https://en.wikipedia.org/wiki/Communicative_rationality Katheryn Sutter PhD has a background in community development and policy analysis, specifically democratic deliberations in organizations. She is also a long-time free-libre and open-source software user and advocate (Debian since 2003). A version of this talk was presented at the Seattle GNU-Linux Confernce http://seagl.org in 2016.