Community Leadership Summit Wiki

Session topics/wants:

  • How to involve outside communities.
  • How to keep people involved and motivated.
  • How to get more up to speed.
  • How often to update people.
  • Dealing with different modes of community interaction.
  • How to manage and assign specific tasks.
  • How to work with particular communities.
  • Migrating FOSS lessons to other communities.

Giving agency to people and getting up to speed.

  • making sure you give people a starting point that works
  • have some sort of greeter, or one-on-one new member orientation
  • keep that welcoming practice going-barriers to code contribution
    • personal attachment
  • have some process for acknowledging work even if action is not possible now
  • teaching people the culture of submitting to an open source project
  • community leaders need to bring these things in
  • we need to figure out what we know and that we know it so that we can share it
    • we have a lot of assumptions with these processes of contribution
  • following the documentation and not having it work probably means the documentation needs updating, not that you screwed up
  • teaching people how to contribute meaningfully so that they feel empowered
  • establish an individual goal/trajectory for each person
    • how can you help them on that path in contributing to the project
  • people coming in won't tell you what they actually need
    • how does this scale?
    • recently new helping the newly new, in public with support from experts
    • make teaching a part of your workflow
  • have a welcome packet/person as a central point

Working with different/non-technical communities

  • some of these communications issues are universal
  • programmers and non-programmers will have different priorities
  • "open source" is not a good selling point if software doesn't do what you need
  • time cost or effort cost of reporting or being involved needs to be minized

Keeping people involved

  • how do you define a project so that contribution is not necessarily development?
  • harder to keep momentum around non-technical contributions
  • with fewer code sprints, more daunting technical issues become the main focus
  • finding more gateway tasks, especially in a mature project
  • lacking a clear set of rules or expectations for contribution
    • "the tyranny of structurelessness"
    • people are afraid of "stepping on a landmine"
  • provide a template or example to get faster contributions
  • clarifying terms and definitions is important
  • challenges in knowledge sharing -- some people want more updates than others
    • levels of updating
      • raw documentation source (e.g., version control commit notes)
      • publish a periodic summary, reference raw docs
      • possibly a higher level, release-related set of notes
    • schedule of updates is important -- needs to be consistent
    • another good example: daily emails at Open Source Bridge, very reliable source of information
    • focusing on the communication is better than focusing on the process
    • important information needs to be captured in a more permanent way

Ideal cases or examples

  • Timbers Army (model of open source and diy culture)
  • Aurora Chorus (harmonzers -- people focusing on smoothing issues)