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)