Core Contributor - Work Scope

Definition

The definition for Core Contributors work is "any scope of work described by an open ticket or pull request on the Open edX github organization, or is listed below in Core contributor work that doesn’t require a ticket."

Reasoning

The intent of this approach is to maximize the proportion of cases where the default situation doesn’t require any work/overhead to get a decision. When 100% of contributors think something is core contributor work, we don't need to discuss it. That should likely be the most frequent case with the tickets and pull requests created on the Open edX github organization - most of them would be an obvious match for core contributor work. 

As long as nobody objects to the scope described by a ticket being core contributor work, it can be counted as core contributor work. It wouldn’t require any additional step beyond ensuring that a ticket for the work exists – which is useful to encourage for better planning and transparency.

Excluding tickets from core scope

When an Open edX ticket or pull request describes scope which a core contributor or their organization doesn’t think should be counted as core contributor time, they can tag these tickets – a bit like Wikipedia page creation & flagging. 

Searching existing tickets

  • Search all issues/PRs

  • Search only issues, excluding PRs

  • To list your issues, you can add assignee:[your-github-username] to the previous searches queries

  • To get a list of issues to mention in your end of sprint update in Listaflow, you can add updated:>2023-01-09 to the previous query, and it will give you the list of your issues/PRs that have been updated during the sprint.

Creating a ticket

  • Go to one of the openedx org’s repositories, then

  • => “Issues” tab (top left)

  • => “New issue” green button (top right)

  • => “Blank issue” → “Get started” green button

Core contributor work that doesn’t require a ticket

Note that this list is deliberately kept small, for cases where there is absolutely no use to creating a ticket – so before adding something to it, make sure to have it reviewed formally on the official forums. Often, even if an individual task isn’t worth a dedicated ticket, there will be a larger task encompassing it that will be useful to have as a ticket. 

Eg. “Open edX translations for the Olive release”We aim to create a ticket for larger chunks of work, up to having one per release, that would encompass all the work produced for a given release. The size of the scope in a ticket can be small or large -- these larger tickets can be broken into smaller ones when useful, adapting to different cases. As long as there is one ticket, small or large (up to a release), whose scope would match the work, it can be considered core contributor work and should be included in a ticket.

The scope of the work that doesn’t require tickets is:

  • Participating in the official forum & Slack

  • Tending the official wiki

  • Attending the working groups meetings

Q&A

Do reviews require dedicated tickets?

No, the work being reviewed should already be part of a ticket on the openedx organization, and that ticket can be used for the review.

Can core contributor work only cover work that only core contributors do?

No. Core contributions can sometimes be made by people who aren’t core contributors (yet?). It’s actually a very good way to demonstrate the skills of a core contributor, to try to become one – by doing the same work as core contributors. Conversely, core contributions are often done as part of working groups, and most working group work would be a core contribution.

Does work on Tutor count?

Yes. Tutor is the community-supported deployment platform for Open edX, so work done within that context counts and is covered by OEP-55 and OEP-54 - specifically, building/maintaining the open source Tutor base and plugins which are officially supported by the Open edX project (this excludes for example Cairn).

Tutor forums are part of the official Open edX forums. It's also possible to pull Github issues from other orgs into openedx project boards by simply adding their URLs in the "+" field of any openedx board view. There are also discussions about moving tickets to the Open edX discourse & github. 

Does conference talk preparation time count?

Yes. The conference is one of the main events that enable the community to function and learn about each other, so all time spent preparing and attending the conference -- venue, scheduling, arranging keynote speakers, volunteering -- count as CC time. We also rely on the conference talk selection committee to choose talks which benefit the community. And so if the talk made it into the conference schedule, it's therefore CC worthy, and time spent preparing it counts as CC.

Does responding to questions in http://discuss.openedx.org count?

Yes. Participants on the http://discuss.openedx.org forum are, by definition, community members, and so helping them use and understand the platform is an important part of community outreach. Similarly, answering community questions on Slack also counts.

As a community, how do we enforce this decision?  In particular, how do we check whether a ticket corresponding to the work doesn't exist, but should?

We wouldn’t be double-checking every answer to ensure that all the work precisely matches the tickets - that would be quite a lot of work! We basically trust core contributors in general, the goal of this rule is more to define the expectations -- ie, that whenever we do core contributor work we are expected to make sure that we have a ticket somewhere on the openedx org for the work, and to post an update in it when we work on it.

How much work is this expected to be for each core contributor, in particular in terms of reporting during the end-of-sprint checkins?

As long as we ensure that a new ticket exists and is updated for the work that we do as core contributor, the only thing this changes for the checkins is to replace the description of our work by a copy-paste of the list of tickets we worked on with their ids. This list can be obtained from search results in the ticket tracker (sample query). This could be further automated in the future, see the suggestion Ghassan made about this: https://gitlab.com/opencraft/dev/listaflow/-/issues/40  

Does time spent on blended projects count as CC hours if tCRIL is paying for the work?

No, because the core contributor program is meant to increase the proportion of the maintenance & core work that is done by the larger community, rather than supported by tCRIL.

What if someone wants to contribute in a new way, and commits to do work that isn’t easily covered by a ticket? Can they add it to the list of items above, based on their nomination review in the forums?

Yes, as long as the nomination explicitly called out the fact that the item would be added to the list, and that there was a consensus in the reviews about adding there, rather than including it in a ticket. To keep the number of places to look at for exceptions low, note that it’s necessary to add it to the list above after the nomination is accepted.

Potential future refinements

  • The proposed mechanism attempts to translate in overhead-free mechanisms a definition of “core contributor work” that encourages working towards the priorities of the Open edX project. A further refinement on this could be to consider whether the ticket is part of the common product roadmap, maybe through some type of an “accepted” status on roadmap tickets, with at least one core contributor from a different organization giving it their . For now though, we tried to keep it simple for the first iteration.

  • It would also be helpful to decide on how to take decisions in cases where there is a disagreement – ie if someone flags a ticket, but another core contributor thinks the work should count as core contribution. Maybe a broader vote of core contributors is held for those cases? 

History

You can obtain more historical information about how the scope of core contributor work was defined by reading the original document submitted for review, which contains the inline comments from the review, as well as the related amendment PR for OEP-54 Core Contributors.