Pattern extraction | Learning By Lurking

[spier]

The blog post Learning By Lurking describes an approach to creating a learning culture in an organization, that reminds us of some of the ideas of InnerSource.

There are also some conversations on twitter about this.

Maybe this is a pattern? However it might be too generic to be a pattern, not sure.

I posted a question on the hackernews discussion of the above article, to find out if the author specifically had an Open Source context in mind, or InnerSource as well.

Leaving this rather unfinished idea here, to see what others think about the blog post.

[NewMexicoKid]

Learning by Lurking looks like two separate patterns:

• Learning by Lurking (a way for potential InnerSource contributors to gain knowledge about the software and on how to contribute to the project, especially valuable when (a) they might be inexperienced and (b) the project members are very busy)
• Supporting Learning by Lurking (a way for busy IS projects to encourage new contributors while protecting their busy project members; the cost of the extra documentation and communications channels is likely less than the cost of having to directly teach and mentor new members or even to try to market the project to users who might later want to contribute)

[spier]

Thanks for the input @NewMexicoKid. Also great to know that others are reading these issues :) In a funny way these issues are my invitation to "learn by lurking" aren't they? 🤯

[spier]

Summary of the blog post for "Supporting Lurkers".

Communications

• Resist "Let me DM you"
• Use private channels sparingly, as they tend to create and reinforce "us" vs "them" boundaries
• Follow up on unanswered questions, including your own

Documentation

• Take note of frequently asked questions and add them to your documentation.
• Explain the obvious.
• Should a question lead to the discovery of a bug or missed feature, capture the information in a ticket. Cross reference the respective issues and conversations. => allow lurkers can discover things on their own)
• As you develop new "things" share early => seed in your lurkers' primary communities what you are planning, allowing them to adapt.

Async Reigns Supreme

(Note: This section lists the benefits of async but isn't explicit about what to do to support lurkers)

• reduce information silos, because you don't have to "be there" or miss out
• minimize rushed decisions, because people have time to think before they type
• enable more easily a one-to-many information flow, thereby facilitating and maximizing knowledge sharing

[spier]

We have two patterns already that are using the word "lurk". Those might be related to the idea that we are exploring here:

• https://patterns.innersourcecommons.org/p/communication-tooling#resulting-context
• https://patterns.innersourcecommons.org/p/issue-tracker#resulting-context

Would be great to hear @MaineC's thoughts on this, as she wrote those patterns.

[allthedoll]

I want to add some anecdotal experience to this: @selkins13 and I worked with an organization for which we hosted open office hours to come ask us any questions. While some people prefer async, and we should default to it when and where possible, some prefer speaking with humans in real time--very similar in attempting to reach a human instead of pressing buttons for a computer during a phone call.

We came to call these office hours Lurk and Learn because people came to just listen to the sorts of questions other people were asking, which lead to some really great discussions. It's easy to get buried in notifications and async conversations, but it's hard to ignore a conversation that is happening in real time.

[spier]

That's a great story @allthedoll. Thanks for sharing.

The "listening in to a real conversation of others" is an interesting variant of lurking, and not one that I would think of immediately. It makes perfect sense though. I can confirm that behavior in video/voice calls from a recent internal unconference that we did at our org, where there was also always a subsection of people "just lurking".

What I find hard with this variant of lurking is that I can see the lurkers, and that makes me uncomfortable as I don't know if the content they are listening in to is relevant for them. One could argue that if the content isn't relevant, the lurkers can do one of two things: 1) leave 2) ask a question or make a statement to make the conversation relevant for them (i.e. leaving lurker status behind)

But maybe there is more that can be done? e.g. ask a question at the end to everybody? Maybe address the lurkers specifically, and say something like:

"For the ones that didn't ask a question today, you can still do that, even in writing/async if you prefer, by going to ."

Question: I the "open office hours" that you mentioned, what would you have thought about recording those, to again increase the lurkability of other async lurkers? I shall try to get this word in here as often as I can :)

[NewMexicoKid]

We actually did a variant of this in the early days of InnerSource Patterns, with regular meetings of the group to discuss patterns, brainstorm new ones, and solve problems that were brought to the group. A number of people would join the call just to listen in; and I would publish the notes from the call afterwards for "lurkers" to learn from (and sometimes to comment on afterwards).

Office hours and Sending notes afterwards are two useful patterns for supporting Learning by Lurking.

[spier]

Thanks for those examples @NewMexicoKid.

Could you share your thoughts on when to merge and when to split a pattern? Or in other words, when to create multiple patterns for given problem, and when to create a single pattern?

e.g. around this topic of "Learning by Lurking" all of the solutions seem to support async communication. Therefore I am leaning towards creating a single pattern that contain all of them. Or to merge even more solutions, one could add them to the existing Communication Tooling pattern.

Any advice would be really helpful here.

[NewMexicoKid]

There are pros and cons (of course) to pattern consolidation vs.individual patterns. Remember that patterns are supposed to represent proven solutions (I think Bob mentioned that there should be at least three instances of a pattern before it is really proven--this is in general, across pattern domains, not specific to InnerSource patterns). When you consolidate patterns, you may be taking parts of solutions that work towards solving parts of problems--at that point, there might not be companies that have the consolidated problem or who have tried the consolidated solutions. In such a case, it might be better to create a meta pattern that points to individual patterns that exist within the general problem superset.

If, however, there is real overlap between individual patterns (problems, solution, context, and forces), then there may be reason to merge them as the real pattern may just be expressed in different instance patterns.

Another thought: individual patterns may be proven solutions to very specific parts of problems. If you consolidate these into a larger pattern, a user who is facing those very specific parts of the consolidated problem may be confused as to which parts of the solution should be applied to solve those.

It might therefore be useful to use the meta pattern concept: this way the users who have the larger meta problem can see the comprehensive, consolidated solution space; and those who have the narrower problems can still see the solutions that directly address those.

Just some thoughts.