Add BBVA as known instance to Core Team pattern

[rahermur]

Add BBVA AI Factory as known instance of the InnerSource Core Team pattern

[spier]

Thank you for sharing this story @rahermur.

I had not seen this yet, so I am reading it right now.
Will review this PR in more detail later today.

[NewMexicoKid]

This looks like a reasonable addition of a known instance to a pattern.
In the past, such additions were more up to the company claiming the known instance since they would know it best (and InnerSource, by its nature, doesn't inherently lend itself well to external review of internal cases). In this particular case, the write-up with the link looks like a clear application of this pattern and so it looks good to me.

[spier]

@rahermur I read through the article now. Absolutely love the level of detail that you are sharing. Thank you so much for that.

I made one observation that I am curious about.

The pattern outlines that the Core Team "doesn't have its own business agenda":

The core team doesn't have its own business agenda that determines its contributions. They decide what to work on based on what will help others most to use and contribute to the project.

However in the case of BBVA AI it looks like the Core Team is also a user and feature contributor to the project themselves. So I suspect they do have their own business agenda? (as highlighted in the screenshot below)

This seems to be a significant difference, worth digging into deeper:

• Does this impacts the behavior of the Core Team in situations where they have to decide between doing something that is good for themselves (and their business agenda) vs something that is good for the project overall?
• If yes, are there any mechanisms in place at BBVA AI that help the Core Team to prioritize the health of the overall project over their own, potentially conflicting, business agenda?

Btw don't get me wrong: We will add this Known Instance to this pattern! I am only exploring if we might extend the description of this with the implementation difference of the pattern outlined above.

I don't want my question to delay the merge of this PR for longer than 1-2 days. So if we find that our discussion takes longer than that, we can move this out to a new issue and continue the conversation there.

[spier]

@rrrutledge curious to get your input here too, as the author/expert on this pattern :)

[spier]

Left a comment on the main thread of the PR for BBVA AI to review.

Looking to merge this within a few days, moving any potentially follow-up conversations to different issues/threads.

[rahermur]

Thanks @spier for your comment! I'm happy to clarify this point. In fact, the purpose of sharing our story is to learn from the point of view of other experts.

The core team of Mercury doesn't have a business agenda. It is a cross team that doesn't solve business use cases. We proactively develop functionality when detecting that is going to be useful for others. For example:

• An external contributor open a PR with a clustering algorithm they have developed. Our team consider that the same functionality, but implemented in PySpark, is going to be useful as well. The original contributor doesn't have the skills or time to develop it. We can take it in our backlog.
• When multiple contributions come from different teams but in the same functional domain it is complicated that they share a similar API. It could be good to refactor the code to gain cohesion and facilitate user experience. That could be another task for the core team, in coordination with the dev teams of the uses cases are consuming these functionalities.

[spier]

Thanks @spier for your comment! I'm happy to clarify this point. In fact, the purpose of sharing our story is to learn from the point of view of other experts.

The core team of Mercury doesn't have a business agenda. It is a cross team that doesn't solve business use cases. We proactively develop functionality when detecting that is going to be useful for others. For example:

• An external contributor open a PR with a clustering algorithm they have developed. Our team consider that the same functionality, but implemented in PySpark, is going to be useful as well. The original contributor doesn't have the skills or time to develop it. We can take it in our backlog.
• When multiple contributions come from different teams but in the same functional domain it is complicated that they share a similar API. It could be good to refactor the code to gain cohesion and facilitate user experience. That could be another task for the core team, in coordination with the dev teams of the uses cases are consuming these functionalities.

In that case it was just a misunderstanding, as it sounds like the Core Team in your case behaves indeed very similar to what is described in the pattern. Thanks so much for clarifying this.

[spier]

@rahermur this is now live at https://patterns.innersourcecommons.org/p/core-team.

Thanks again for helping us to improve this pattern.