Pattern idea: "Contribution negotiation"

[MaineC]

In reading through some of the patterns in the initial phase in the "reluctance to accept contributions" I came across a cross reference to a pattern idea that I found interesting:

"Contribution negotiation"

The solutions discussed in "Reluctance to Accept Contributions" include the "30 day warranty" pattern, but also clear process and guidelines around how to submit contributions. The pattern does not talk about expectation management around which types of contributions would be interesting to the host project. It also does not discuss any negotiations or communication that may occur before the changes are made and submitted. In our contributor training (in the Learning Path) we discuss some of that in more detail: Contributions start not with submitting the patch set. Rather contributors should reach out to the host team before making modifications to seek guidance on whether the changes make any sense in terms of roadmap, general architecture and the like. A side effect could be that the host team offers mentoring time thus reducing the time to implement a modification. Such communication would be particularly helpful for larger changes. The entire communication should happen in project channels that are company-wide accessible, archived and linkeable so they can be referenced in the future.

[lenucksi]

Fully agree that we already have this in the learning path. Depending on the size of the contribution its also a common Open Source pattern. It could also fit in nicely with make Agile and InnerSource cooperate, as highlighted and practiced by @rrrutledge repeatedly.
What - given the nature of organizations and their inbuilt desire to plan the unplannable - should be highlighted as a detrimental force here is the risk of overplanning and thus death by bureaucracy for such efforts. One of the repeatedly academically proven mandatory aspects of InnerSource is voluntary participation and action. Making it SAFe might be a bit too safe. ;-)

[spier]

@MaineC thank you for exploring this idea here.

I edited your post and added some links to the material that you are referencing, to make it easier for other people to follow the conversation.

I believe I got all links right but would you mind checking?

[MaineC]

@spier the links you added look complete and seem to be the right ones.

[MaineC]

Depending on the size of the contribution its also a common Open Source pattern.

https://mahout.apache.org/developers/how-to-contribute ... "Before you start, you should send a message to the Mahout developer mailing list (note: you have to subscribe before you can post), or file a ticket in our issue tracker. Describe your proposed changes and check that they fit in with what others are doing and have planned for the project." ... I am sure that other projects list similar requirements. Would it make sense to keep references to how this works in Open Source in an InnerSource pattern?

It could also fit in nicely with make Agile and InnerSource cooperate, as highlighted and practiced by @rrrutledge repeatedly.

Do you have any links to such conversations?

What - given the nature of organizations and their inbuilt desire to plan the unplannable - should be highlighted as a
detrimental force here is the risk of overplanning and thus death by bureaucracy for such efforts. One of the repeatedly
academically proven mandatory aspects of InnerSource is voluntary participation and action. Making it SAFe might be a bit
too safe. ;-)

I fully agree here. What I have observed in practice is that InnerSource can give teams a middle ground:

If a change is large enough, submitting it as a fully fledged patch at the beginning typically will lead to frustration and friction as review is tedious and takes a long time. However staying out of coding for too long means spending too much time in natural language conversations that tend to be more vague than code. So a workflow that often works better often has some of the following ingredients:

• Check the host project's roadmap to see if there are any very obvious blockers (submitting a patch that goes against the mission of the project will be futile)
• Send a quick note to the project to test the water
• Only when met with resistance support your point with an architecture decision record that helps understand the various tradeoffs you already thought about so you don't have to discuss them again
• Start working on the change together with the host team by sharing progress early and often - GitHub even has a WIP feature for it's pull requests for that.

The sharing early and often tends to be something teams need to learn - even if it doesn't quite work, even if there are mistakes in it. This also needs a high level of trust in the organisation that mistakes are allowed.

[rrrutledge]

It could also fit in nicely with make Agile and InnerSource cooperate, as highlighted and practiced by @rrrutledge repeatedly.
Do you have any links to such conversations?

I think I've just talked verbally in calls I've been on.