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.

5

@maxim There can be different scenarios, but a canonical example of something being contributed upstream as a plugin would be an XBlock - it uses a modular technical interface and a stable API provided by the XBlock plugin system, but could still be something the upstream project would accept. We have for example the Drag and Drop XBlock, Problem Builder, etc. which are now upstream plugins. Now with the focus on getting the core minimal and implementation moved to plugins, this extends to more and more parts of the platform.

Note that being upstream doesn’t mean that someone else necessarily maintains it - it can actually be a good way to solve cases where another maintainer wouldn’t want to take on the maintenance burden, by accepting to take on the maintainer role for it. It is still useful to contribute the plugin upstream in such a case, especially if the plugin is included by default with Open edX, as it still allows to ensure that other people’s changes upstream won’t break it without noticing (minimizing the drift/upgrade burden), guaranteeing the quality (to be accepted upstream at all), and that the work is contributed for the larger community to benefit.

1 Like
6

@antoviaque

Under the Q&A for that page, it says that Blended projects (aka Funded Contributions) from Axim do not count towards CC hours.

Is this still true?

7

@jill Yes - since work funded by Axim is development or maintenance that they provide and that the goal is to develop the part that the rest of the community provides, Axim-funded contributions don’t count as core contributor work.

1 Like