CLSxAU17: Reworking old communities clsxau17_reworking_old_communities

1. TOPIC: Reworking old communities (Notes by Rikki Endsley)

-- Mark Atwood asked who's had to refactor an old community to start discussion -- then round table to discuss topics of interest to attendees

== Why are attendees interested in this topic (and what do they hope to learn from discussion)? == -- reasons included:

• Pick your battles and know what not to do (esp. in old communities) -smith

• How to steer communities in a positive direction when they have been the way they are for a long time

• Community has "stuck in the mud mindset"; we have people who have behaviors, and "codes of conduct" are still an issue (adopting them, convincing team that they need it) ** Attempts at CoC have led to language discussions, what CoC could be used for (in negative ways)

• Interest in long-term communities (attachment to communities) is it better to have something in a list (pleasing left brain)? or better to go from "feel" (pleasing right brain)?

• Cat Allman wanted ideas for revitalizing communities

• FreeBSD project - Gamergate period affected FreeBSD community; members were publically disagreeing (in non-productive ways)

• Tim - gaming background has much different approach (wants to learn what other communities are doing)

• Julius (Unix sys admin background) - learning how longer-term members of open source communities are adapting to more modern/recent approaches to community and communication styles

• Linux kernel developer - wanting to learn about steering historically hostile communities into more inviting direction

• Mark Atwood - ntp project (older community) had toxic personality harm community

• Cheree - observing and wants to learn what's working for other open source communities

== Questions: == 1. How do you change a community to adapt to a new model/approach? 2. How do you change a community to attract new members/communities?

== Codes of Conduct discussion ==

• ToDo Group: saw that Codes of Conduct were important (e.g., in context of working for corporate open source offices) they put the outline of a code of conduct up into a git repo; included preface explaining it was rough draft and asking for feedback result: open source community members took to social media to criticize/flame ToDo group for publishing draft (i.e., the outline) w/out first consulting specific people/groups. Soured a member [who was part of the CLS discussion] of ToDo (e.g., he was harassed as part of the fallout) to the topic of CoC.

== Discussion: == * the reason you codify (eg CoC) is so when you need to remove members you can refer to the document that outlines expectations for behavior and ramifications

• another problem is when you put topics to group decision, getting a decision/consensus can be a problem

• use of word "toxic" to describe a person/behavior is problematic

• If a community has a codified list of rules (CoC) and you don't like it, you can leave the community or work hard to change it Over-codifying is a problem (too many rules) but implied rules are harder to enforce because they aren't clear enough ** if rules are open enough, organizer/community leader has discretion to decide outcome (eg ejecting person)

=== Back to... How do we rework an older community? === Does the new person in the community push for change? (will they have the voice/authority) Or does the community look at what they have to change to attract those new people?

• Codes of conduct are living documents and should be regularly reviewed and revised as needed.

• Will adding or attempting to add a CoC improve the community/situation (or not)?