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
4 years, 9 months
Weekly status meeting coming 27 Feb Thursday 11:30 PDT/19:30 UTC
by Karsten Wade
Join us for the weekly status meeting with folks working on The Open Source Way 2.0 guide.
We are also having some high-bandwidth foundational discussions, which we endeavor to bring back to this list in all instances. We are balancing the need currently to move quickly to prepare for the upcoming workshop at SCaLE, with the need to have async transparent decision making.
How are we doing?
For this meeting this week:
Join by phone -- +1 413-853-2059 PIN: 266 410#
By web browser -- https://meet.google.com/yzs-hpgb-iwf
https://github.com/theopensourceway/guide
This contributor meeting is open to all participants, and is held under our Code of Conduct [https://github.com/theopensourceway/guidebook/blob/master/CODE_OF_CONDUCT.md]. This invitation is open to all.
This audio and video of this call is recorded and will be shared publicly under a CC BY SA 4.0 International license as a content artifact of this open source project https://theopensourceway.org
== Status of repeating meeting
20200219 -- Trying this out in real-time, hoping that all the parts work. In the interests of being fair to peoples' time and the desire to be a fully transparent project, we will spend up to five minutes resolving any issues in real-time. If we have some people unable to join, we can work toward resolving their issues for the next week.
4 years, 10 months
Editorial project board
by Bryan Behrenshausen
Greetings, all.
I've been working on a new project board for tracking our editorial work
and wanted to share it (along with a bit of context!). You'll find it here:
https://github.com/theopensourceway/guidebook/projects/1
## The workflow
The project board is a kanban-style board designed to help The Open
Source Way authors and editors visualize progress writing and editing
the book's contents.
When they appear, editorial issues ("something needs to be written,"
"something needs to be expanded," "something needs to be edited,"
"something needs to be corrected," etc.) will go on this board. They'll
move along the editorial workflow through the following steps, each of
which is represented with a different column on the board.
The workflow proposed here operates like this:
To Assign: Project managers have identified the issue as an editorial
issue and placed it on the board, but haven't yet assigned anyone to
work on it.
Assigned: Someone has agreed to write or edit material that addresses
the issue, and it's been assigned to them.
Drafting: That writer is now composing the material addressing the issue.
Draft Review: The writer has finished the draft and would like project
managers and editors to review it. Project managers and editors will
determine whether the writing sufficiently addresses the issue. If it
does, the card move "forward" to "Editing." Otherwise, it moves backward
to "Drafting."
Editing: An editor is now reviewing and making editorial changes to the
material. If the editor determines that additional work is necessary,
that editor will move the card "backward" to the appropriate column
(i.e., back to "Drafting" if more writing is necessary, or to "Draft
Review" if authors and project managers should simply take another look
to confirm something). If the editor deems the work complete, then card
moves "forward" to "Formatting."
Formatting: A technical editor is reviewing the writing and "marking it
up" (in AsciiDoc) if it's not already. As part of this process, the
technical editor ensures that the work conforms to other technical
parameters (line spacing, footnote formatting, etc.) and will "compile"
as part of the book.
Final review: Project managers and any other stakeholders who may need
to review the work one more time have the opportunity to do so here.
Completed: Finalized issues are moved here; they're closed closed, and
their associated materials are merged.
## Sections, chapters, topics
The project board conceptualizes The Open Source Way as comprised of
"sections," "chapters, and "topics." Sections contain chapters. Chapters
cover various topics.
As initially outlined,[1] the book consists of these sections:
- Introductory Material
- Attracting Users
- Guiding Participants
- Growing Contributors
- Measuring Success
- Avoiding Pitfalls
- References
Each of those sections has a corresponding "label" in the repository.
We'll assign chapters to sections. When we've determined the section in
which a particular chapter should be included, we can attach that
section's label to the issue associated with the chapter. For example,
the proposed chapter on "participant motivations" will likely appear in
the book section dedicated to guiding participants, so it gets the
"Guiding Participants" label in our repository.
Each section will contain several chapters. Chapters begin as issues
filed in the project repository.[2] At minimum, issues proposing new
chapters should elaborate:
- The subject, aim, and scope of the chapter
- Potential topics the chapter might cover
Modifications to or suggestions on chapters also appear as issues.
Project managers will triage these issues and, upon recognizing them as
editorial issues, assign them to the editorial project board (see above!).
Each chapter will cover several topics. Readers can file issues
suggesting new topics for chapters, revisions to existing topics, etc.
As topics expand, they may become their own chapters. As chapters
expand, they may become their own sections.
... and that's as far as I've gotten!
Feedback certainly welcome.
----
[1] https://github.com/theopensourceway/guidebook/blob/master/OUTLINE.adoc
[2] https://github.com/theopensourceway/guidebook/issues
4 years, 10 months
Meeting notes for 06 Feb 2020 team discussion w/ video
by Karsten Wade
As we are moving our work on The Open Source Way entirely to the external-from-Red Hat open community space, one of the last bits is the video conference meeting we have once a week.
We captured this bit from our meeting as a best-effort-at-the-time toward transparency and accessibility especially for participants and contributors:
https://bluejeans.com/s/zUfmt
(Please let me know if you have any issues accessing that, I'll do the best I can. We didn't discuss it per-se in that video but our intention is to release content via this project under the CC BY SA 4.0 International Unported IIRC license. I'll make sure to have us state that in the videos in the future.)
This guide has been part of a larger editorial discussion for our team in the Open Source Program Office at Red Hat, and we use these weekly sessions to keep on track for active project work.
We're ready to have these meetings entirely where anyone from the community can join, observe, and participate. I would like to see us do that for the next meeting we have scheduled, which is 20 February.
We're willing to work quickly toward having meetings that work for many timezones; this one happens to line up nicely for our US-based folks who are attending after their morning-with-European meetings. It's something to discuss.
This meeting covered the following topics IIRC:
- We gave an enthusiastic account of the Birds of a Feather session from FOSDEM.
- We talked about project management, getting a milestone-based schedule, and where to do that. We settled on continuing to use the tools that GitHub has to offer, with the caveat our commitment there is only for the 2.0 release and can--and will--review other options for the future when we catch our breathes post-2.0 release.
- We did not discuss actual release dates, that's for us to figure out here and in the meeting.
- We may have discussed some of the SCaLE workshop logistics.
I haven't re-watched this one since we had the meeting and do not have good contemporaneous notes. But I've been stuck getting this out and I have the few minutes right now to write up the best note, and anyone who watches feel free to chime in this thread with notes and/insights.
Our intention aside from a high degree of transparency is a higher degree of accessibility. At the moment, we are falling short of that goal. We feel that moving as quickly as we can in that direction while doing the best we can does the best job of--at the least--leaving a trail that can be made more accessible over time.
Best regards,
- Karsten
4 years, 10 months
List of sections that require content? FOSDEM 2020
by Ashley Nicolson
Apologies if this is jumping the gun, but I would just like to express my interest in picking up any of the discussions/sections that were jotted down from the Dev Room.
There were a lot of good sections to be introduced. Is there a visible overview of sections that require 'content'?
4 years, 10 months
List of sections that require content? FOSDEM 2020
by Miss Aran
Apologies if this is jumping the gun, but I would just like to express my
interest in picking up any of the discussions/sections that were jotted
down from the Dev room.
There were alot of good suggestions to be introduced. Is there a visible
overview of sections that require content?
4 years, 10 months
