Clsx takeaways

From LCA2016 Delegate wiki
Revision as of 18:42, 23 January 2016 by Donna@kattekrab.net (Talk | contribs) (2015 breakout discussions)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


clsXlca 2015 Takeaways

We summed up the day by sharing our take aways from the day. Turns out to be a nice summary of the day's discussions.

  • Post it Thank Yous. See http://instagram.com/p/xz1NAHFGt8/
    B7Qr4w3CEAEBDhX.jpg
  • Support - how do we support our communities? Doing this stuff is hard. Supporting the work is key.
  • Communicate and Collaborate (this was echoed by others too) and soon, and often. Don't keep it to yourself. Share.
  • Burnout is a thing.
  • Inspired to get my community going, and will write a blog article sparked by ideas today. Culture!
  • Recognition: working towards a recognition culture across, up, down and the tree.
  • Types of recognition. Just ask.
  • Surprise! Pleased that these conversations are happening.
  • It's possible to generalise the issues.
  • Recognition is important. The non-code work is hard to measure.
  • We don't have to solve ALL the problems. Sometimes they solve themselves, sometimes they just stop being problems.

Code of conducts are important. We need them now. Stop procrastinating.

Understanding what other people are doing validates what we're doing too and shows how and where we can improve.

NOTES

Agenda

  • Context Appropriate Tone
  • Protecting your community - umbrella'ing
  • funding, budgeting and fundraising
  • community manager therapy
  • docs process
  • hiring
  • metrics
  • one off advice
  • best and worst practices
  • marketing
  • breakouts
  • sustainable handover and pipeline
  • burnout, retention and recrutiment
  • diversity - correct vs importance
  • management
  • problement people and managing them
  • creating engagement leadership diversity
  • succession planning
  • managing conflict
  • governance and politics
  • lifecycle growth / wind down - detecting mission accomplished
  • inductions and introductions
  • how to recognise all contributions - how and feel part of the community
  • making people feel safe - and flipside - people who make our communities feel unsafe
  • creating a truly *global* community
  • interdisciplinary skills - and working across domains
  • choosing not to be offended if you have the ability to


Order of events

  • Introductions
  • Agenda from the room
  • dot voting on topics

Talks

  • Clinton Roy - diversity- and how it affects people's lives, and the difference it can make
  • SUz - diversity within the fab lab - think about poeple who have been excluded on the basis of difference - who have been excluded from the school system. Peopole who are unemployable - people need time and patience to help them become useful.
  • Tridge - project leaders as umbrellas. Came about linuxcare auslabs joined IBM, Hugh Blemings was the manager withi the group - part of his job was to act as an umbrella - to protect the geeks. In some communities, discussing all this stuff up front is good, but in others this can be a barrier because they don't want to have to think about all the peripheral stuff - they just want to code and send packets. A lot of communities the project leader bears the brunt of this stuff - ie leader as an umbrella.
  • Victoria - human being - until I was welcomed into the group I was an outsider, and Donna welcomed me. This is all about welcoming and introduction. How do you know what to do? Do people want to be welcomed? You have to ask your community. What is the right welcome for your commuity? They will know how to raise issues, they will feel safe, because it is part of the welcoming practice. You need to tell people how to get involved. Talk to your people - find a way to speak to them individually.
    • Donna additional: code of conduct, this is where it is, EULA - this is where the rules of engagement are.
  • Darrell - changing funding paradigms. How groups maintain funding. In AU now, small groups are being defunded because they are seen as not effective. But the small groups are effective - but you're not seen as effective if you don't make a profit - so there is a pressure to make a profit. As one example Lifeline is now spending their time running a book fair, and selling solar energy and coffee so that they can be sustainable financially. The issue is though that the people who call Lifeline now are put on hold, because Lifeline cannot take all their calls - because they are busy selling books and coffee. Is this the right way for non-profits to work? We have non-profits because we've found that some services are best run by non-profits because those services are not seen as valuable by government, which is validated by conversations by politicians. Services are increasingly user-pays - particularly for social servies, and this is where AUstralia's social services are headed. This is a call to action to revers ethe trend.
  • Joshua Hesketh - succession planning is very important for the strength and helath of the organisation. Josh is tryin to encourage the pipline for Linux Aus council. If you'r einvolvedin the community, how do you want to be involved in the future of the community. Part of this picture ismentoring - ie having someone come in at a junior level and mentoring them up. If you're burning all your members out, maybe you *should* shut down.
  • Adam - learnings from dealing with problem behaviours at MakeHakeVoid. Paassive aggression was our first step, and it was a mistake. Then, engagement turned to the mailing list. Engagement with the problem behavoiur using the medium they were using for the problem behaiour didn't work either. Instead, a safe space was created for a converation, and a trusted friend was present, and the conversation directly addressed the problem behaivours. Unfortunately the mailing behaviours moved into the person to person space. His behavioru contributed to the burnout of others, so we tried to address it. We tried to established new rules and behaviours. We found we were stacking rules upon rules and it was unsustainable. We realised that the community that he wanted wasn't the comunity we wanted. The person needed structure and predictability, whereas the Hackerspace needed more flexibility. This was met with threatening behaviour from the person, and legal action. The next stage was a thrid party mediator. The parties wanted different things from the mediation process and was less than successful. Finally an email was sent where the person was excluded from attended. The lesson is that sometimes excluding someone *is* the right decision. Unfortunately the person is also on another local group in the area and I'm now in conversations with the leader of the other group about the person's behaviour.


2015 breakout discussions