Improving the measurement of our contributions

Discussions - Public
1

The recent discussions about contributions budget have shown that we are currently not measuring our contributed time very well. And since we are discussing time commitments at the community level, it’s important to start to get more reliable figures for it.

We use the “CoreContributor” tag rather than a specific account, as that time can be provided by different budgets, either internal ones or billable. Currently though, we usually only tag the non-billable “contribution” tickets (ie work sponsored purely by OpenCraft) and the upstream reviews done by core contributors. We leave aside the largest part of our contributions, namely the client work that we contribute upstream - so we will need to go back and properly tag the tickets done over the last year, to include the full range of work that is part of the core contributor scope:

The definition for Core Contributors work is:

Note that this include work done by non-core contributors, as long as it matches this definition. And all work done on tasks that are contributed upstream counts, not just the additional work necessary to have it merged upstream – when we work on something that we contribute, it qualifies.

So there are a few next steps on this:

  • Update our handbook and our processes to ensure that we properly identify and tag tasks that qualify, going forward – and keep an eye on the numbers as part of MNG-2649.
  • Create tasks for the whole team, to have everyone spend 30 minutes going through their tasks since the beginning of 2024 to tag the ones that qualify
  • Report on the overall result for 2024 and the beginning of 2025, to get an idea of the exact amount of work/time we currently contribute.

Would anyone be willing to take on this mini-epic? This can be a dedicated additional budget, to add to the contribution account.

[ Ticket to log time answering on this thread ]

2

@antoviaque How would we measure time on a ticket that includes both upstream and non-upstream work?

For example, if we’re working on a frontend plugin and create frontend slots for it, the work will likely be in the following categories:

  • Changes to the MFE to support plugins (CC work)
  • The actual frontend plugin (non-CC work)
  • Cherry-picks to our custom branches (non-CC work)
  • Deployment config and deployment of client code (non-CC work)

Do we need to track all this separately? The time spend in these categories can vary widely from ticket-to-ticket.

3

@kshitij We should still aim to contribute the plugins to the project, so imho all of this would often qualify. Even if they aren’t integrated in the default distribution, they could still go upstream - the fact that we use plugins is a technical distinction, which should not remove the upstream contribution from the requirements. Plugins should also be developed with an upstream-first approach.

4

@antoviaque Could you please help me understand what does it mean in practice (e.g. what should we do differently to what we are doing right now)? I’ve re-read your comment a few times, and it just doesn’t click for me.

Also, the thought that comes to my mind that conflicts with “upstreaming the plugins” is that often for us the plugins are the answer to the situations when we can’t contribute code to an existing project, because the owners of the project don’t want to have to maintain that code (recent example of that is tutor-forum broke compatibility with MongoDB and refused the fix because in their eyes that was adding maintenance burden, so they suggested to us to write a custom plugin) or because the use case is not useful to enough people to be accepted upstream. What I am trying to say is that most of the time plugins are the code that was already refused by the upstream. There are exceptions, but I feel like there has only been 1 or 2, while all the other plugins fell under the things I’ve described before.