How do we handle engineering-led issues that don't belong to one team?
Discussion from https://gitlab.com/gitlab-org/gitlab-ce/issues/41430:
It's one of those issues that got assigned to the ~Platform team because it used to be a catch-all for anything that didn't fit anywhere else, but with all backend teams now focused on specific product areas and ~Platform having been split up into ~Create and ~Manage, there is no team to take on these kinds of backend-wide, non-product-area specific issues anymore
Even if we had a team that was in place to handle issues like this one, there will always be boundary conditions. As Product is responsible for prioritizing work, if we need to do any horse-trading or other determination to figure out where the work should land, I think that's something that Product should work out (in this case, between @jeremy_ and @jramsay).
@tommy.morgan This would be an engineering-led initiative though, so it would need to be pushed by a specific EM, not a PM.
Issues like this affect all backend teams equally, so we fall prey to the bystander effect. When an EM gets to make room in a given release for an engineering-led initiative, they have the choice between issues like this, that any team could pick up, and product area-specific issues, that aren't going to get done unless their team does it, so the latter will have a far higher chance of being picked.
Everyone cares about these kinds of issues, which means no one cares.
If we had a team in place to handle issues like this, there wouldn't be any boundary conditions if define the team's responsibility as "every engineering-led initiative that doesn't fall into a specific product area" :)
[...] the extra complicating factor here is that no individual EM or PM will feel like an issue like this is theirs to prioritize, because it isn't specific to their product area.
[...] there are many issues (technical debt and otherwise) that aren't currently anyone's responsibility, so they won't get done.
We have also seen this in https://gitlab.com/gitlab-org/gitlab-ce/issues/39147, and @marin mentioned it for https://gitlab.com/gitlab-org/gitlab-ce/issues/48991. To use some concrete examples:
- Rails 5 ended up on my team because I really wanted us to get it done. But, I can't spend much capacity on it.
- GraphQL ended up on @DouweM's team for a similar reason.
That's not really a process, though.