Shape of a chapter
by Karsten Wade
I had a discussion this weekend with Amber Graner, and was struck by her
recollection of the short, meaningful phrases that are hallmark of the
1.0 release. This is not the first time I've heard that from folks--the
original focus on PIE (principle, implementation, example) for
what/how/why had the effect that we kept the 'what' to a very short,
focused sentence or two.
In this new version we want more of a narrative flow, and I also think
we don't want to lose the summary-short statements that get to the heart
of the matter.
Here is what I've been thinking for the format of each chapter, which is
informed by all the recent discussions:
1. Title
2. Summary aka tl;dr -- summary of salient points from the chapter,
offering a chance to give the main points in short, memorable phrases.
3. Main content -- bulk of writing goes here
4. Stories of why -- the chapter author brings some of these stories,
but they can be swapped out with other stories from the
interview/story pool
5. Lexicon -- capture of various special terms in the chapter so there
is one place explaining the terms.
It's the summary/tl;dr that acts most like the 1.0 chaplets, for example:
http://www.theopensourceway.org/wiki/How_to_loosely_organize_a_community#...
So the memorable phrase in that example is from Karl Fogel, "Making
important decisions in private is like spraying contributor repellent on
your project.
<http://producingoss.com/en/setting-tone.html#avoid-private-discussions>"
Writers main concerns would be around 3. the main content, from which
the tl;dr and initial stories-of-why arise.
How does that sound to you?
- Karsten
--
Karsten Wade [he/him/his]| Senior Community Architect | @quaid
Red Hat Open Source Program Office (OSPO) : @redhatopen
https://community.redhat.com | https://next.redhat.com | https://osci.io
https://theopensourceway.org | https://github.com/theopensourceway/guide
4 years, 11 months
Ready for writing -- call for writers
by Karsten Wade
Fellow open source practitioners,
We are pleased to announce:
The Open Source Way 2.0 is ready for you and your pen and your paper --
let the writing begin!
The initial sections and chapters have been finalized in a process that
included a Birds of Feather session at FOSDEM 2020 in Brussels and a
workshop at SCaLE 18x in Pasadena.
https://github.com/theopensourceway/guidebook/blob/master/OUTLINE.adoc
What chapter(s) are you interested in writing?
You can express your interest in writing a chapter, ask questions, and
share ideas including your initial outline by commenting on the issue
that is associated with the chapter. Take a look in the "To Assign"
column to find the issues, which are tagged by section of the guide:
https://github.com/theopensourceway/guidebook/projects/1
For your general interest and broader discussions, our contributor
forum/mailing list is the perfect place:
https://lists.theopensourceway.org/archives/list/contrib@theopensourceway...
The Editorial Team would like to hear about your interest (via issue
and/or mailing list) and see your initial chapter outline by 07 April,
with an eye toward a December 2020 guide release.
https://github.com/theopensourceway/guidebook/wiki/2.0-Release-Schedule
If you are interested in more than writing--such as reviewing, editing,
content tooling, and so forth--please join us on the
contrib(a)theopensourceway.org forum/mailing list and let us know your
interest.
Best regards,
- Karsten
--
Karsten Wade [he/him/his]| Senior Community Architect | @quaid
Red Hat Open Source Program Office (OSPO) : @redhatopen
https://community.redhat.com | https://next.redhat.com | https://osci.io
https://theopensourceway.org | https://github.com/theopensourceway/guide
5 years
Notes from the FOSDEM BoF
by Shaun McCance
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
5 years