Create unreachable-communication-channels.md

[Trueblueaddie]

No description provided.

[fioddor]

I think we could merge this with the Communication tooling pattern. WDYT @spier, @Trueblueaddie, @MaineC?

[spier]

@fioddor the Communication Tooling is making the unspoken assumption that it is possible for all user and contributors to reach the issue tracker as well as the public/private discussion channels of the respective InnerSource project.

Therefore the issue outlined in this PR here needs to be solved first, before the Communication Tooling pattern can be used effectively. Or maybe a more nuanced statement would be:

If you don't have a single communication platform for all legal entities within your organization then you can only do InnerSource within a single legal entity but not between multiple legal entities. In other words, you won't be able to capitalize on the full potential of InnerSource in your whole org.

Now whether to merge this PR into the existing pattern: I don't know.

Keeping the patterns concise and focused on a single problem has its merits. So if we think that many orgs will have this issue (siloed communication platforms), then we could keep this PR as a separate pattern.

One other question about this PR:

Can you elaborate on the specifics of the solution in this case? Was the solution to

a) to migrate everybody to a new and shared communication platform
b) to establish a new communication platform where only InnerSource-related communication is taking place

Personally I would favor (b) but I suspect that this would not be realistic for larger orgs? Not sure.

[MaineC]

I agree that this pattern would be a pre-requisite to implement the Communication Tooling pattern.

I would suggest linking this one from the Communication Tooling pattern, but not merge the two.

Why?

I like that this pattern is so consise. I believe keeping this issue in a separate pattern helps readers find the pattern related to their challenge more quickly. For organisations looking towards InnerSource to address their silos I would assume that this problem is a very common one.

[MaineC]

Can you elaborate on the specifics of the solution in this case? Was the solution to

a) to migrate everybody to a new and shared communication platform
b) to establish a new communication platform where only InnerSource-related communication is taking place

At least GitHub comes with a third option:

c) Open up visibility of InnerSource projects on the existing communication platform.