Split up responsibilities for developers

[oliverschuerch]

As the design system grows and we add one to three new packages to our codebase throughout the year, it might be beneficial to split responsibilities per package so that each maintainer/developer is only responsible for, or at least only works on, some of our packages in the monorepo.
However, this does not mean that anyone is excluded from making decisions in a particular package, it just means that each of us can focus on his/her part of the whole project.

A similar idea could be to divide responsibilities per milestone instead of per package.

Before we discuss/define further in this direction, e.g. who would be responsible for which package/milestone, we would like to know if you feel it is worth thinking about at all.

Please let us know your opinion and cast your vote.

[leagrdv]

I think it'd be interesting to discuss this topic to see how we could solve the ever growing project. But overall, I feel like splitting responsibilities is not always a good answer:

• If only one person (or two people) really understands a package, the team becomes dependent of that one person which might be an issue with vacations or other blockers. This is something we saw with Alessio and the tokens, when he was on holidays we were kind of blocked on token creations, hence the tokens handover which was done to avoid that issue.
• Same goes with priorities, if something becomes really urgent on a package, we might have less "competent" people (in that topic) to work on it. Having a broad knowledge of all of the packages is more efficient as everyone can try and help where they can.
• Inconsistency between packages as different "owners" might have different coding styles or testing workflows, etc which might lead to less coherence between the packages.
• We might miss some learning opportunities by not taking tasks that are not assigned to our "own" packages.

[gfellerph]

There are some packages that I feel everyone should feel responsible for, mainly the styles and components. I'd rather not give any single person responsibility for those. Also, I think there are some things to consider when discussing ownership:

• It will be harder to distribute work load between team members since the thinking of "this is Xs thing and I dare not touch it" will eventually establish itself automatically, so far I've tried to fight that mindset
• We have to be aware of Conways law and how it will influence the way the packages work together. If we split up responsibilities, we're also splitting up communication channels to some extent

In general, I think taking responsibility of a milestone makes more sense since it's a limited time venture, gives people responsibility to take decisions and allows to focus on this for a while.

[alionazherdetska]

I'd prefer exploring milestone-based responsibilities rather than package ownership. This approach:

• Gives clear ownership for a defined timeframe
• Encourages knowledge sharing across packages, allowing everyone to understand different areas of the codebase
• Maintains collective ownership of core packages (styles/components), preventing bottlenecks when team members are unavailable
• Prevents the "that's not my area" mentality and dependency on specific team members, fostering a more collaborative environment
• Allows for focused work while preserving team flexibility and adaptability as project needs change over time

[alizedebray]

I definitely agree with the comment above and would prefer to split responsibilities by milestone rather than by package. However, for this to work, we’ll need to define the concept of a milestone more clearly, which was also discussed as part of April’s monthly. For example, the maintenance milestone probably doesn’t need an owner.

[gfellerph]

Agree, Sandra is working on a better framework to formulate and describe Milestones - especially that all of them have a clear goal. Even the Maintenance Milestone could have an assignee or two. Their job would be to identify and define tasks that reduce tech debt, increase performance, build time, fix security holes, etc.