Elaborate on why one should be SLOPI?

[skilfullycurled]

The walled garden article and the project page on the website is making me wonder about (in a good way!) is what are the overall benefits of SLOPI communication are. More simply, why? This is something I think a lot about in design because I used to be really into participatory design for which I think SLOPI communication would mesh really well with. Participatory design hasn’t fallen out of favor with me I just don’t have a patient enough temperament! ; ) So I think a lot about the “why”. Does it have to do with a better way of achieving a goal, or is it simply a matter of values?

[vsoch]

or in summary... "So what?"

[skilfullycurled]

@vsoch, unfortunately they don't have a laugh emoji but even so, I wouldn't quite say that. I'm not sure exactly what the difference is but the following two statements mean different things to me:

P1: We landed on the moon! P2: Why?

vs.

P1: We landed on the moon! P2: So what?

The answers that would come of the first question would probably be about all of the science-y stuff we could learn (while really sticking it to the USSR), and the second would have answers in the realm of how difficult of an endeavor it is to get there (while sticking it to the USSR).

Edited to better reflect the entity we were trying to stick it to.

[vsoch]

I'm parroting an advisor I had when I did an internship at a finance group in Boston - I'd present an argument, and some specification, and he'd look at me and say "So What?" The idea is that if you are presenting an idea, if you don't get at the "So What," or why people should care / follow in the first place, you've failed.

[vsoch]

I don't understand the "sticking it to" part, but I've expressed what I meant by my comment. Thanks!

[pdurbin]

@skilfullycurled thanks for opening this issue! All of the projects listed at https://good-labs.github.io/projects/ have a "Why do we need it?" section and this is what I wrote there for SLOPI:

Why do we need it?

"Open source projects are adopting Slack, forgetting the importance of public and open communication. How can your users and contributors know what you’re thinking if the majority of discussion and decision making is done in Slack? Did you forget that you have a mailing list with public archives? Have you considered chat tools that support a SLOPI communication style? Should the discussion happen on the public issue tracker?"

I should elaborate on this and include it in the README or elsewhere in this repo. Thanks for the reminder!

[skilfullycurled]

@vsoch, again, no laughing emoji but I was just having a conversation about advisors one of whom skips "so what" and goes straight to "that's boring".

With regard to the "sticking it to" part, I'm referring to the way in which going to the moon was politically motivated by the space race between the US and the USSR. So if asked either "why" or "so what" the answers would have to include both science and politics.

[skilfullycurled]

@pdurbin, yeah, another thing that your Slack comment makes me think about is the way in which "freemium" can feel like openness. For example, a lot of groups that I'm in that are on Slack would say that since it's free, it's accessible and since anyone can join, open. But I think the history is limited, no?

[pdurbin]

@skilfullycurled a lazy way for me to answer why (for open source projects) is to link you to my article at https://opensource.com/open-organization/17/11/transparency-dataverse-project which I am very eager to have feedback on. A few quotes:

• "Working transparently helps the Dataverse team communicate changes to current development efforts, provides opportunities for the community to support each other, and facilitates contribution to the project."
• "In short, development is an open book, and the community can follow along with every chapter and even help tell the story."
• "As adoption of Dataverse has grown, the community has become better able to support itself. Community members ask and answer questions in public channels, building a knowledge base accessible by any search engine. The team encourages the community to be bold about posting questions to the mailing list and the publicly logged IRC channel. The community is eager to help all members succeed, and the strengths of individual community members shine through."
• "By having conversations in the open, the community keeps abreast of current efforts of their counterparts at other institutions, or even the same institutions."
• "Putting information into the open - rather than in private emails and messages - maximizes the value of our keystrokes."

[pdurbin]

@skilfullycurled thanks again for opening this issue. I just merged pull request #18 to link to this issue from the README to encourage discussion here. Of course it's fine to discuss at https://gitter.im/good-labs/community and anywhere else as well! :smile:

[pdurbin]

@vsoch thanks for reminding me over at https://github.com/good-labs/greater-good-affirmation/issues/24#issuecomment-493269735 that a previous version of The Greater Good Pledge said, "The community strives for open communication for discussion around development."

Here's a link: https://github.com/good-labs/greater-good-affirmation/blob/24d049c2ae6966522dafc351869444b619625b90/GREATER_GOOD_PLEDGE.md

Now that https://github.com/good-labs/slopi-communication exists (the canonical reference for now: https://github.com/good-labs/slopi-communication/issues/3#issuecomment-492880850 ), maybe we can link to it if we add that bullet like that about open communication back in the pledge.

[pdurbin]

Another lazy way to talk about why is to link to these issues:

• Add reference to "We will not hide problems" commitment from the Debian Social Contract #4
• Add reference to "Open Communications" from The Apache Way #5
• Add reference to "Single Source of Truth" from GitLab #6
• Add reference to "Considering the Use of Walled Gardens for FLOSS Project Communication" by @megansquire #7

Perhaps the "why" is buried in one or more of these references.

Also, in addition to "why" I should probably answer "why not" and further elaborate on situations where the SLOPI style is completely inappropriate.

[pdurbin]

Perhaps the "why" is buried in one or more of these references.

Today I updated the README quite a bit, adding the following sections:

• Open source organizations that favor a SLOPI communication style
• Companies involved in open source that favor a SLOPI communication style

I think some of these entries help explain some of the "why".

For example, here's a quote I added from the GitLab team handbook:

"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."

I also added this quote from the Mozilla wiki:

"open: Public and participatory. This requires structuring efforts so that "outsiders" can meaningfully participate (and become "insiders" as appropriate)."

I should probably spell out my take more explicitly but I feel like some of the quotes above help tell why being SLOPI can be beneficial.

[ysuarez]

Here is my take on why we need SLOPI...

I have benefitted from working with a handful of open source projects using what we would now would call SLOPI communications. For example, on several occasions I was trying to use a feature in the software and/or to create/update documentation for it, and it did not work as expected or I just did not understand how to use it. There was sometimes documentation, though I often wanted to understand why the feature existed, how the code actually worked, and how the feature should be best used. I of course had access to the whole code base, but the codebase was large and complicated enough (in a good way) that I needed help. I was usually able to find added information about the code by first looking at the relevant code commits that in that community's rules required that the corresponding bug/feature reports IDs needed to be listed. With the bug/feature ID number(s) I could search the public bug/feature lists, chat logs, and mailing lists to find relevant communications to that feature.

All those platforms were SLOPI compliant. For example, in the community public chat you had a chat helper that would automatically create permalinks to both code commits and bug/feature reports if you just sent the ID/hash number. At the same time in the bug/feature reports the community would put permalinks to a specific chat message. You could also easily search the chat logs and bug reports through Google or inside the bug/feature report platform.

The SLOPI nature of these community platforms allowed me to often to find the necessary background context of why a piece of code was written and why it was written the way it was. It was extremely useful to create this fuller picture by easily looking at information from commits, chats, emails, and bug/feature reports and their comments.

Sometimes the code commits, chat messages, email messages, and bug/feature reports were many years old, but because of their SLOPI nature of them, I could find them and get the necessary context. Of course, there are times I could have turned to the community for help, but I often try to do some research before I ask for help. Though when the community uses SLOPI practices you all of a sudden tap into a sort of cross-linked web of information that it is efficient and event enjoyable to follow along first, before asking for more help/context from the community.

On the topic of old messages, I have used Slack for basic workplace communication, but I am just starting to use it for close development and some open source development work. So far in this limited experience I have been invited to development channels that were not open to the public. Therefore, I need to experience how easy it is to join a truly open channel belonging to a FLOSS project. I also need to learn how easy it is to search for information like commit hashes and issue/feature/bug numbers in the Slack UI like I did in my example above. I also worry about the 10k message limit for free Slack accounts/channels. What if when I need to track down a very old Slack conversation explaining why code was written one way versus another, by the time I run my searches the relevant Slack messages may have been purged for being past the 10k message limit?

Of course, if an open source project that has very detailed documentation and code commit messages, maybe you won’t find yourself often trying to replicate my scenario above of trying to figure out the context why the code was written that way. Though you often find yourself in that scenario if you are the one writing the documentation for said feature. To me the bottom line, on a project that has good documentation and thorough commits you can still need more context.

Another situation that I have benefitted from SLOPI messages/communications is when I want to research if anyone in the community has considered using (for example) technology “X". I again have poured through the SLOPI commits, bug/feature lists, chat logs, and mailing lists to see if anyone has ever brought up technology “X,” so I don’t have to start my brainstorming from scratch or perhaps find a replay good but old answer why technology “X" is a dead end that won’t die.

[pdurbin]

@ysuarez thanks for all the thoughts above and for chatting with me about this blog post I wrote today: http://blog.greptilian.com/2020/01/25/slopi-communication/

@skilfullycurled since you opened this issue, I'm hoping you can take a look! To get back to your original question, I feel like it's mostly a matter of values. In the blog post I try to explain the free and open source software have a long history of transparent communication but these days lots of open source projects are using Slack for the bulk of their communication.

@vsoch your feedback is always welcome, of course!

[pdurbin]

Again (a couple years later), the additional elaboration is in http://blog.greptilian.com/2020/01/25/slopi-communication/

In 3c1861c I linked to this blog post of mine in the README under the the heading "Canonical reference for SLOPI" as a response to this issue:

• 3

I'm going to go ahead close this issue but I'm still happy to get feedback on that blog post by @skilfullycurled and anyone reading this. Please feel free to either comment on this issue or open a new one. Thanks.