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