Support shared ownership of components

[MrHadiSatrio]

Feature description

When a component is declared to have multiple owners, Ruler would report it as such. On the JSON, owners can be outputted as an array. While on the HTML, we can present them in a way so that the component size would be divided equally amongst the teams that own it.

Here's how it could look like on the HTML:

Breakdown	Ownership (main-team)	Ownership (lib-team)	Ownership (dynamic-team)

As for the JSON:

{
    "name": "com.spotify.ruler.sample",
    "version": "1.0",
    "variant": "debug",
    "downloadSize": 632328,
    "installSize": 635818,
    "components": [
        {
            "name": "org.jetbrains.kotlin:kotlin-stdlib:1.6.20",
            "type": "EXTERNAL",
            "downloadSize": 614171,
            "installSize": 616811,
            "files": [
                {
                    "name": "kotlin.collections.ArraysKt___ArraysKt",
                    "type": "CLASS",
                    "downloadSize": 151781,
                    "installSize": 152428,
                    "owners": [
                        "lib-team",
                        "main-team",
                        "dynamic-team"
                    ]
                }
            ],
            "owners": [
                "lib-team",
                "main-team",
                "dynamic-team"
            ]
        }
    ]
}

Reasoning

Not every organization has the privilege of having a dedicated team to maintain third-party dependencies / libraries. In such cases, it'd be best to attribute them as something that every teams would own.

[MrHadiSatrio]

I'm open to take this up should you guys are aligned with the idea. 😃

[simonschiller]

Thanks a lot for opening such a detailed issue!

I'm personally against the idea of adding support for shared ownership because in my experience shared ownership really means no ownership and nobody really feels responsible for a thing. This article sums it up pretty well in my opinion. For me the main benefit of having defined owners is that you have a clear person or team to talk to if there are issues with some component and having multiple owners kind of defeats this (i.e. do I go to the first or the second team owning this).

That being said I understand that for smaller teams it's not feasible to have an owner for everything. But I'd argue there are better ways of dealing with this than shared ownership:

• If there's something that is really owned by everybody (say i.e. the Kotlin standard library), it's best to mark it as unowned than artificially assigning owners that really don't have full ownership of this.
• If something is owned by two or more teams, then it should be split up. During this process, one team should take ownership and make sure that the split actually happens.

That's my two cents on the issue. Maybe you or the rest of the team have different thoughts, but in my opinion we should be opinionated here.

[MrHadiSatrio]

My pleasure. Thanks for taking the time to consider this request. ❤️

Your points are very valid. I agree that having clear-cut ownership for every component is important. However, I also feel like the feasibility to adhere to this principle is highly situational and that baking it into Ruler could limit its usability as a tool.

If there's something that is really owned by everybody (say i.e. the Kotlin standard library), it's best to mark it as unowned than artificially assigning owners that really don't have full ownership of this.

I'd argue that shared ownership may be better than no ownership in this case. At least with the former, you'd get to know whom to reach out to. Explicitly marking components as unowned may yield a false perspective that anyone is free to do anything without any repercussions whatsoever. Which in my experience is rarely the case.

If something is owned by two or more teams, then it should be split up. During this process, one team should take ownership and make sure that the split actually happens.

IMHO, this is a better approach to the problem. But again, very situational as I feel a lot of friction could happen during execution. On smaller teams, bandwidth could become a problem. Larger ones may see overlapping priorities preventing such exercise to be done in a timely manner (if at all).

To summarize my point, this looks like a problem that should be solved through proper management and organizational alignment. Ruler as a tool should remain unopinionated and defer this decision to the user.

[ViktorPetrovski]

Hey, @MrHadiSatrio first of all thanks for your suggestion.

I've read your comments and @simonschiller as well and agree on the points made around the ownership, but also agree on the point that Ruler as a tool should not decide that and is okay to support teams that want to have multiple ownership per file.

This feature request does not fit on our priority list, but if you are willing to contribute we would be happy to review the PR.

[simonschiller]

I understand that and while I don't agree it's obviously up to you if you want to support this or not. But if we want to do we have to carefully think about a few questions, because shared ownership has a few implications:

• How should we split the size across owners? Uniformly or using some other strategy?
• How should we display sizes in the "ownership per team" view? Only the partial size or the total size? Both solutions have trade-offs. If we show partial sizes, the actual size of files owned by many teams could be hidden. If we show total sizes then we might end up in confusion situations where one team owns 10MB, another one owns 20MB, but the whole app is only 25MB.
• We have to overthink wildcard matching. Right now if one team owns :foo:* another team can own :foo:bar:*. How should we handle that now? Arguably I would expect :foo:* to also include :foo:bar:* and therefore :foo:bar:* would have multiple owners. But that might not be what existing users would want, so maybe we need to provide a mechanism to differentiate.

There are probably also things I didn't think about yet. But we should think this through before we start implementing it.

[rezastallone]

Feature description

When a component is declared to have multiple owners, Ruler would report it as such. On the JSON, owners can be outputted as an array. While on the HTML, we can present them in a way so that the component size would be divided equally amongst the teams that own it.

Here's how it could look like on the HTML:

Breakdown Ownership (main-team) Ownership (lib-team) Ownership (dynamic-team)

As for the JSON:

{
    "name": "com.spotify.ruler.sample",
    "version": "1.0",
    "variant": "debug",
    "downloadSize": 632328,
    "installSize": 635818,
    "components": [
        {
            "name": "org.jetbrains.kotlin:kotlin-stdlib:1.6.20",
            "type": "EXTERNAL",
            "downloadSize": 614171,
            "installSize": 616811,
            "files": [
                {
                    "name": "kotlin.collections.ArraysKt___ArraysKt",
                    "type": "CLASS",
                    "downloadSize": 151781,
                    "installSize": 152428,
                    "owners": [
                        "lib-team",
                        "main-team",
                        "dynamic-team"
                    ]
                }
            ],
            "owners": [
                "lib-team",
                "main-team",
                "dynamic-team"
            ]
        }
    ]
}

Reasoning

Not every organization has the privilege of having a dedicated team to maintain third-party dependencies / libraries. In such cases, it'd be best to attribute them as something that every teams would own.

I ended up creating script to generate ownership for individual files that's in shared module. the steps is as follow :

1. read the package of a file in shared module
2. look up similar module name or package that already has owner in the ownership.yaml
3. define new ownership with fully qualified file name and the owner in ownership.yaml

I was able to breakdown the shared module and mapped the individual owner.