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)?
