Pattern idea: Great first impressions

[spier]

In InnerSource much like in open source, the very first interaction between a contributor and the maintainer of a project sets the tone for the rest of the interaction.

That first impression can

1. turn a first-time contributor into a raving fan of the project, leading to more future contributions
2. or scare of that user, maybe even prevent a first-time contribution that otherwise would have been possible

The importance of the first impression goes both ways though!

e.g. a user that starts the conversation with "we should really fix this stupid bug" may create some negative vibes in the conversation that are frustrating for the maintainer to deal with.

While overall project appearance and documentation also contribute to the first impression, in this pattern idea I want to focus on the elements of human interaction that make a great and not-so-great first impression. We could say "be nice" but does that really cut it?

Some questions:

• What are behaviors of InnerSource maintainers that made you (as a user) want to contribute to that project more?
• What are behaviors of an InnerSource project that have made you (as the maintainer) want to help them more?
• How do code reviews contribute to this? In some projects these might be the "first impressions", assuming that the user opes the conversation by proposing a code change through a PR

What are anti patterns for great first impressions? e.g.

• maintainer opening the conversation with "please create an issue first ..."
• user opening the conversation with "we should really fix this stupid bug"
• ... more examples like these (especially some that are less obvious :))

[spier]

@rrrutledge I believe you have a lot of relevant experience in this field. Would you mind having this conversation with us here in the open? (we are trying out GitHub Discussions)

[spier]

Literature collection:

[spier]

First hit that I found related to first impressions in open source:

Managing First Impressions of New Open Source Software Projects
https://www.researchgate.net/publication/224107180_Managing_First_Impressions_of_New_Open_Source_Software_Projects

[spier]

Does it matter how fast the first response from the maintainer is?
Does it matter how fast the issue is resolved? Especially wondering about this if the first interaction happens during a contribution by a user.

[lenucksi]

My experience:
First response: Yes in any case. Very important. Few Days, not weeks. The larger, the more commercial, the faster.
Turn around time to merge - very stretchable. As long as expectations are clear and the host team reacts accordingly everything will usually turn out. Entitlement on either side will break things - as usual with FOSS.

[spier]

If the contributor starts the interaction with the project/maintainers through a PR, then the first impression will be defined by the quality of the code review i.e. the feedback that the maintainer provides to the contributor.

gitlab is defining there reviewer values like this:

• Aim to not get bogged down in smaller issues that have no real bearing on the overall code quality of a merge.
• Avoid the introduction of technical debt and strive for its reduction.
• Encourage but don't demand boring, simple solutions.
• Consult your fellow reviewer often, but be conscious of a delay for the author, especially when there is a large difference among time zones of the people involved.
• Take into account the far-reaching impact of the changes and whether the code makes the overall codebase better or worse. Everything is a tradeoff.
• Be careful when introducing dependencies and consider their side effects.
• Admit when you don't know something.
• Be kind, friendly, and humble.
• Avoid demanding. Coach and teach instead.
• Lean towards a bias for action and collaboration. For velocity, don't be afraid to fix linting errors for authors if the rest of the merge looks good to you. If you are confident, fix them to be able to merge immediately and avoid another round of reviews.
• Make a safe space for people to fail safely, make your own safe mistakes, and try innovative approaches. Welcome creativity.

[spier]

There are also interesting aspects about code reviews in here:
https://zguide.zeromq.org/docs/chapter6/#Development-Process

e.g.

Maintainers SHALL NOT make value judgments on correct patches.

or

Maintainers SHALL merge correct patches rapidly.

[lenucksi]

The Gitlab values sound sane and like a good practice.

[lenucksi]

Interesting subject. I would point out clear expectation management regarding the house rules is of huge importance. E.g.: if the project is large and wants a well written issue first, they should get it as long as they describe what they'd like to see, e.g using an issue template and provide automation for tedious, repetitive work where possible.
@dicortazar had a paper on the establishment of trust over time in FOSS through contributions. It was interesting but probably only after the 2nd contrib etc.