Pattern idea: Communication tooling setup about innersourcepatterns

[spier]

@MaineC just wondering if this issue is actually already fully implemented, given that there are 3 PRs related to it that are already merged? Or did you still want to add more to it?

[spier]

I am considering this one done. We can always reopen it again or file a new issue with further pattern ideas if people disagree.

[rrrutledge]

Great addition, @MaineC

[ericshanda]

Is there need a pattern that tells new innersource team how to choose communication tools.

[lenucksi]

I don't know if there's a pattern in this repo but research and the mentioned OSS world has the following:

• Everything should be archived, indexed and equipped with stable links
• There are mostly two classes of tools: (rather) synchronous and rather asynchronous communication oriented tools. It can help to provide an instance of both classes.
  • First class: Phones (not archived, indexed, ...), chat systems such as Slack, IRC, ...
  • Second class: Mailing lists, bulletin boards / forum systems, ...
  • Second class too, but slightly different due to the workflow tracking nature: issue trackers (such as this one)
• All tools can be "creatively repurposed" to serve as the respective other class. They also do not strongly enforce or even ensure any behavior. Your community still needs to make sure that they are used in a proper way.
  • This might need some learning and some explicit community-wide agreement on how the tools are supposed to be used.
• Try to learn about the preferred communication habits of your community members - some only like mailing lists, some like slack or forums more. To ensure visibility of important messages it can sometimes help to use bots to sync channels or provide digests.
  • Try to focus on as little channels as possible though.
• Try to do as much in the open as possible, i.e. prevent discussions being holed up in 1:1 discussions.
  • This might need some work to enable people to safely discuss WIP and possible learning (clueless -> having a clue) in the open, which will in the end boils down to psychological safety.
  • Take into account this tweet though: https://twitter.com/kentbeck/status/851459129830850561 or else you might end up in "yeah, someone needs to do this" distributed denial of responsibility and effectively block your project.

[spier]

@MaineC 💥first PR in the series merged. Great stuff!

I understand that #123 and #124 will add more tools to the project-setup/ folder.

Some questions:

• project-setup/base-documentation.md describes a proven pattern at your company, right? Shall. we set the status as Proven?
• So that readers can find this pattern, should we add a link to it to the main README? While doing that, let's add a Patlet as the high level summary of problem/solution.
• What was the intention for project-setup/templates? I could find any links to those files, so how would readers find those?

I am happy to help with any of the above, just wasn't sure of how this was "meant to work", so first wanted to check with you.