Hi friends, We ran a BoF discussion at FOSDEM around our efforts to revamp TOSW. I took some notes, and Erin McKean was kind enough to send me her notes. I've compiled some notes below from mine and Erin's. --- There was some discussion around what kinds of contributions (and what kinds of contributors) you want to encourage, and on the flip side, what kinds you do not want to encourage. For example, how do you handle well-meaning attempts to clean up the code base that break API? --- There's interest in advice on running events. Running a major conference is probably out of scope, but there are lots of tips for running smaller events and hackfests. --- Is it possible to scale down the guide for smaller projects? Some projects don't need all the information. Can we have a journey thru the guide that's relevant to newer or smaller projects? --- How do you deal with toxic contributors? And how do you deal with the mental health of moderators and community leaders when they have to deal with toxicity? --- Is it impersonal to just put this all in a written guide? Part of the motivation for writing the guide is to have something to reference when people ask about open source, but is telling them to "RTFM" really the best way? --- There was some discussion on whether to talk about projects, initiatives, or some other term. We seem to be preferring project, but that is very software-centric. --- For profit-generating projects, how to you reward contributors when there's money flowing, especially outside employment? Does paying contributors disincentivize people from contributing without pay? --- How do you get funding and resources? Corporate sponsors are a source, as well as programs like Summer of Code and Outreachy. There are services with free tiers for open source projects. It was pointed out that these services change frequently, so the content might not be as evergreen. Job for an evolving wiki? --- There was considerable discussion about generalizing the guide to non- software projects. A lot of the planned material is relevant to all sorts of communities. There's definitely interest in including examples from other free culture movements (music was brought up as an example), but we don't want to stray too far. --- There was further discussion about writing in a modular fashion, which could allow topics to be reused with different examples. Modular writing is good, but can create a barrier to entry if done too much. --- How do you resolve conflicts between stakeholders? Aside from personal conflicts, there can be legitimate differences in technical direction that can affect how your project progresses. --- A lot of what we discussed was about running distributed communities across the globe. How do these concepts translate to situations where you're meeting people in-person? --- There was general discussion about metrics, but one concrete question was how do you decide when you need more community leaders? --- How do you define a vision, roadmap, and project goals? How do you prioritize these goals and get community feedback when prioritizing? --- How do you handle loss of contributors, offboarding, and succession? Relatedly, how do you decide when to end a project, and are there processes for ending gracefully? --- Some discussion on forking or taking over projects, and in particular how legal stuff like trademarks comes into play. Thanks, Shaun