How to start an InnerSource project when groups members are distributed about innersourcepatterns

[MaineC]

What are the challenges that you would like to solve?

Being distributed from the start in my experience actually makes it easier to arrive at a working Inner Source project, as the focus on written communication and asynchronous communication turns out to be a no brainer. With co-located teams moving vital communication to a written medium often takes a bit of explaining and reminding.

Some question to get started with your question:

How distributed - how many time zones do these cities span? This might inform the time you will need to allow for decisions to be finalised.

Are your team members on board with running this project in an Inner Source fashion, or are you asking for support to convince them?

Which kind of version control, issue tracking, chat systems do you have in place?

Are those people already used to asynchronous communication?

I assume they are embedded in teams that are each local to one location?

[MaineC]

I think non-familiarity with asynchronous could turn out to be a challenge:

• Ranging from discussions happening outside of project channels.
• Not knowing what to discuss where.
• Feeling intimidated by the paper trail generated, that includes all mistakes made.
• A lack of bandwidth in written communication.

All of those can be solved, but in my experience that looks like the most obvious issues to watch out for when starting.

[MaineC]

... with the one caveat of bringing decision points identified in ephemeral communication channels back to a medium that gets archived, is searchable and linkable such that your decisions, your reasoning behind those decisions become a reference for the future.

[lenucksi]

I agree with the written hints. Also, that sync+digital would work. However, I can not stress the importance of a written culture with searchable, linkable and archived records enough as @MaineC already did.
Making Post-Hoc or on the fly records is great too - but often this does not capture everything. Just doing everything in written, archived and indexed and public (having most of the things in 1:1 chat rooms that are archived but private does not really bring the full advantages) already generates a sufficient amount of "passive documentation" that will help you.

[ericshanda]

@MaineC Thanks!

• My team members are distributed on different cities, but all in China.

• We plan to run this project as an InnerSource way and I am the project manager.

• We use gitlab behind our firewall and use wechat or inner im tools to communicate.

• Those guys are not very familiar with asynchronous communication.

[ericshanda]

I have learn about Bertrand Delacretaz: Asynchronous Decision Making – why and how? https://www.youtube.com/watch?v=HPjYa_O6yEk

We plan our asynchronous decision making with gitlab.

[rrrutledge]

If you're all in China things don't necessarily have to be asynchronous - they could be just digital and synchronous. You'd need to commit at least to running the project digitally, though, I think.

[rrrutledge]

Think of running standups, backlog grooming, design review, etc. via chat and conference call rather than in-person meetings.

[ericshanda]

I start the project with gitlab and Wechat .