Skip to content
Searchable Linkable Open Public Indexed (SLOPI) Communication
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
CONTRIBUTING.md tasks have been created, suggest sharing ideas May 27, 2019
README.md highlight archiving part of walled garden paper #7 May 27, 2019

README.md

Searchable Linkable Open Public Indexed (SLOPI) Communication

Gitter Kanban https://good-labs.github.io/greater-good-affirmation/assets/images/badge.svg

Messages written in the SLOPI (pronounced "sloppy") communication style are:

  • Searchable: Messages can be found using Google or other search engines.
  • Linkable: Messages have a permalink on the web.
  • Open: Messages are in the open.
  • Public: Messages are public.
  • Indexed: Messages are indexed by search engines.

This phrasing, especially with regard to messages being searchable and linkable, is inspired by the discussion criteria of Core Infrastructure Initiative (CII) Best Practices program.

Examples of communication tools that support the SLOPI style include:

  • mailing lists with public archives
  • public forums
  • public issue trackers
  • Gitter
  • IRC channels with public logs
  • XMPP rooms with public logs
  • public roadmaps
  • public kanban boards

(As part of issue #2 we are gathering examples in the wild in a spreadsheet.)

While open source projects should endeavor to communicate in the SLOPI style whenever possible (as discussed in issue #12), this style is inappropriate for security, code of conduct violations, and telling co-workers on your floor that you brought in donuts.

The SLOPI style can take some getting used to if you are new to open source culture. It's ok to be a little sloppy. Please don't worry if the message you send isn't perfect. The fact that you sent it in the open is appreciated. Open source is getting friendlier. A thick skin isn't as necessary as it was in the past.

Open source organizations that favor a SLOPI communication style

The Apache Software Foundation (ASF) requires open communications

The Apache Way indicates an embrace of open communications, saying (emphasis added):

"Open Communications: as a virtual organization, the ASF requires all communications related to code and decision-making to be publicly accessible to ensure asynchronous collaboration, as necessitated by a globally-distributed community. Project mailing lists are archived, publicly accessible, and include:

  • dev@ (primary project development);
  • user@ (user community discussion and peer support);
  • commits@ (automated source change notifications); and
  • occasionally supporting roles such as marketing@ (project visibility),

...as well as restricted, day-to-day operational lists for Project Management Committees. Private decisions on code, policies, or project direction are disallowed; off-list discourse and transactions must be brought on-list. More on communications and the use of mailing lists."

Debian will not hide problems

Commitment 3 from the Debian Social Contract is "We will not hide problems" and is expressed in this way (emphasis added):

"We will keep our entire bug report database open for public view at all times. Reports that people file online will promptly become visible to others."

Companies involved in open source that favor a SLOPI communication style

Gitlab has most company communications public on the Internet

The Single Source of Truth section of the "GitLab Values" chapter of their team handbook states (emphasis added):

By having most company communications and work artifacts be internet-public, we have one single source of truth for all GitLab team members, users, customers, and other community members. We don't need separate artifacts with different permissions for different people.

Mozilla has an FAQ and resources for when, why and how to work open

Mozilla's Working open FAQ came out of a 2013 Practicing Open talk and has the following to say under Open vs. Transparent about moving from "passively transparent" to "open" (emphasis added):

  • transparent: Public, but not necessarily enabling participation.
  • passively transparent: Not private; decisions aren’t actively hidden, but are difficult to locate. They may not even be documented. This is usually not done intentionally.
  • actively transparent: Everything is written down, is easily searchable and is locatable by interested parties. This requires intentional, sustained effort.
  • open: Public and participatory. This requires structuring efforts so that "outsiders" can meaningfully participate (and become "insiders" as appropriate).

Academic research

Considering the Use of Walled Gardens for FLOSS Project Communication by Megan Squire

In Considering the Use of Walled Gardens for FLOSS Project Communication Megan Squire argues that transparency in decision making is a key value in many free, libre, and open source (FLOSS) software projects, often achieved through publicly archived mailing lists. She names a number of projects with publicly logged IRC channels such Ubuntu, OpenStack, Puppet, Perl 6, and many Apache projects. She describes an increasingly popular practice of using Slack and among the 18 projects she surveyed "the majority of projects which are using walled gardens are not creating archives of these communications." She argues that "archives preserve a record of decisions and can help bring new contributors up to speed."

Contributing

We love contributors! Please see our Contributing Guide for ways you can help.

You can’t perform that action at this time.