#lkml

[robotic-anarchy]

im at 200k unread emails

[informatici]

Quando Linus si incazza di brutto.

[lovelydistinguishedgentlemen]

“And yes, a large part of this may be that I no longer feel like I can trust "init" to do the sane thing. You all presumably know why.”                  — Linus via @nixcraft

[post-millenial]

Open Source Decency

“There is no such thing as a structureless group. Any group of people of whatever nature that comes together for any length of time for any purpose will inevitably structure itself in some fashion. The structure may be flexible; it may vary over time; it may evenly or unevenly distribute tasks, power and resources over the members of the group. But it will be formed regardless of the abilities, personalities, or intentions of the people involved.”

Jo Freeman, “The Tyranny of Structurelessness”

Last week a handful of coders, all of whom I deeply respect, decided to leave the linux community. These are all people who love the technical challenges. But the personal challenges and the complete lack of desire for maintainers to foster a community of decent human behavior is ridiculous. Despite flimsy attempts to improve developer conduct, insults and abuse still remain.

Sarah Sharp has a follow-up post to the one linked above, where she links to more resources about open source community building that I encourage everyone to check out. In it she discusses six levels of what makes a good community, which I’m recapping here:

Level 0: basic human decency

From the ground up, the community needs to be welcoming. Community leadership needs to be invested in and actively developing and enforcing social norms and rules. Honest and direct technical feedback should still be encouraged,  as should healthy resolutions of disputes. Contributors who repeatedly personally attack and insult other members should be encouraged to change, and repeat harassers should be removed and banned.

Microaggressions should be pointed out and listened to, and the community should be aware of trolls to warn newcomers to the community.

The key here is a communication/behavior standard and leadership that actively enforce these standards. Gina Likins, whose relevant talk is also referenced in Sarah’s post, mentions several research studies on open source communities, including one that shows that Linus Torvalds insults contributors about twice a week, and another that suggested over 20% of the emails on the high-volume LKML list were negative or aggressive. (Yes, people do research on the communication that happens out there in the open. Surprise!) 

Level 1: on-boarding

“The next phase in improving diversity is figuring out how to on-board newcomers.”

The community shouldn’t have major barriers to entry; diverse newcomers should be encouraged to stick around. This means documenting how to interact with the community, video/in-person meetups to encourage networking, and to promote civility by putting faces to names.

First steps for contributing, web harnesses for testing, and updated step-by-step tutorials should help newbies get on their feet. The community’s coding styles, release schedules and non-code contribution steps should also be provided.

Level 2: meaningful contributions

Give newbies things to do! In my experience this is one of the most challenging stages. Todo list, self-contained subprojects, mentorship, programs to encourage/compensate new contributors, ways to acknowledge and give immediate feedback to new contributors can help immerse people in your development community.

Level 3: succession planning

A community that gets to this level needs retention planning. How do you keep and promote influential newcomers in your project? People want to have a say in making decisions. Reviewers should be rewarded and leadership should be rotated. People should take breaks! So that backup maintainers can practice and learn their skills. Community members should write tutorials on patch reviewing, release management, and the social side of leadership.

This level also includes mentorship for conference presenters, codes of conduct to encourage burnout and of course encouraging respect for those who do choose to leave.

Level 4: empathy and awareness

Open source is cool because nearly anyone can participate-- as long as their voice isn’t being drowned out. The community should value all contributors (coders, non-coders, bug reporters, etc.) and focus on non-technical issues including cultural and political issues. People should be able to call people out, and leadership should be able to recognize their mistakes and change accordingly.

The community should provide some level of a support system for listening to different perspectives.

Level 5: diversity

“It’s an alienating feeling, being somewhere clearly not built for you. High shelves just out of reach, not enough automatic doors, hallways not wide enough for crutches. Loud conversations at non-circular tables, unplanned social gatherings with no prior accessibility information, no stairs except the little infuriating bump the wheelchair won’t go over.”

- David Peter, “Accessibility Culture”

At this level, new voices are a major part of gatherings, familiar voices are in rotation, and people reach outside of their network when searching for new leaders. Diversity programs and honest efforts to seek out different perspectives should be a major part of the community.

Conferences should be welcoming, inclusive and accommodating. Gender presentation should be a non-issue, accessibility should be built in the design, child care, dietary preferences, event policies, and alcohol policies should all be thought out and made explicit. The code of conduct should explicitly protect diverse developers.

----

I think Sarah’s notes are a good start for a framework for a diverse open source community; however, most communities I’ve participated don’t even meet the first baseline of basic human decency. Why do we continue to allow our technical leaders to act like children? 

[conundrum]

Presumably because freedesktop crowd has made an architectural mistake and pushed dbus as solution to all problems. And ran into limitations of that, er, solution. Then, instead of perhaps reconsidering the wisdom of their inspired decision, went for "let's push it kernelwards, it might somewhat reduce the overhead and problems will be easier to chalk up to something wrong being done by the kernel".

Al Viro, ladies and gents — aren't we glad that LKML has gotten better?

[forteilusao]

Booa sorte a nóos dois . (oito)  ' .