Open edX 2022 Lisbon: Birds of a Feather

Core Contributor Governance

We have this notion of “Core Contributor”. There is an expectation that a CC will work 20h/month in service of the Open edX Open Source project. However, it seems this may be a high bar for individuals, those working in small firms, or those with limited knowledge (for example: a translator maintaining a translation or an XBlock developer just maintaining that block). Have we set the bar too high? Is it working? Should we make a distinction between “ecosystem firms” versus smaller firms/individuals when assessing a commitment to the program? How should we handle those who cannot make their commitments for a period of time? (one thought: Karl Fogel, p 186 "Dormant Committers). How do we treat everyone in the community fairly - making sure people aren’t driven from the project for doing too little, feeling like they’re doing too much, and not discouraging newcomers?

See https://discuss.openedx.org/t/conf-bof-governance-topics/6841 for pre-conference discussion.

Other core contributor governance topics suggested in the thread:

Non-technical decision-making - Product decisions & reviews?

It might be a topic for the product working group and @jmakowski, but since product decisions directly affect the direction of the project, there is a part of this which is related to the overall project governance. It’s also a topic which is at the center of the changes created by the edX/tCRIL organizational split, and it would be imho important for the community at large to understand and buy in on the approach. This will, sooner or later, be what decides whether a change a contributor wants to make to the project is refused or not. Having a clear process and making sure the expectations are correctly set will be important – it will have a huge impact on the feeling of empowerement (or powerlessness) of contributors.

Questions to discuss:

• Is there already a process agreed to or being discussed for this?

• Who are the people who will be doing product reviews?

• If there is a disagreement, who makes the final call?

• Does it make sense to formalize this “permission” (accepting/refusing a product change) as part of the core contributor program, like for technical decisions?

Defining maintainers vs core contributors

There have been some discussions and brainstorming about how maintainers and core contributors roles relate to each other on OEP-55 - it would be a good occasion to discuss those face to face:

Discussion thread on OEP-55:

Note that the core contributor role, as I understand it, is meant for the really involved and active contributors - with significant commitments from their organizations, generally at least 20h/month. My feeling is that we have a lot of repositories, components, etc. If we require all maintainers to become core contributors, it would probably work well for most large active projects/repos – but it might be tricky to find enough maintainers for all the components?

It could be good to keep this role open to smaller time investments – someone could want to become maintainer of a standard XBlock or small module for example, and we wouldn’t need them to be as active/involved as a “core” developer, as long as they keep maintaining it it’s useful to the project. We have already this situation a bit with some of the current core contributors actually, who are maintaining smaller things for which 20h/month is more than needed, or core contributors don’t have enough time to give. Maybe we could use the maintainers on smaller / less active repos as the “low commitment” contributor role?

Some would choose to be a maintainer as well as a full core contributor (there are many other things/projects they can work on to get to 20h/month), or commit only as a maintainer, and fulfill the corresponding responsibilities when it’s needed, but with potentially a smaller workload than full core contributors on smaller repos or less active parts of the code base.

Maintainer time/duties would be part of core contributor duties, since it encourage to take both roles? Maybe we could even as core contributors also all become maintainers of something, even if it is small?

[…]

How to help to safeguard core contributor time/efforts?

This topic is closely related to the one you posted above @sarina – it could either be discussed together, or separately, but there would be links between the discussions. You make the (good) point that we need to be careful to adapt the level of involvement to the size/capabilities of the core contributor organizations/individuals – it is important to be realistic with this, and be open to smaller structures & individuals.

Once we have that, the other side of the coin would be to figure out how we can help core contributors who are part of an organization to actually reliably obtain the time (or whatever work was agreed to by the organization) from their organization, afterwards. As many of us know, it can sometimes be difficult in practice – there are always a lot of conflicting priorities, and the reality is that it often takes second place to client work.

• For core contributors, what would help you to actually be able to block the time or context meant to be reserved for core contributions?

• For organization owners/managers, what could help to prioritize this work further? Is there any additional incentives which could make the core contributor more of an equal, in terms of priorities, to client work?

@Sarina Canelake

@Sarina Canelake @Feanil Patel @Xavier Antoviaque @Andrés González @Esteban Etcheverry

Connecting Product Workflows with Engineering Workflows

As we develop rituals and artifacts to support an end-to-end product management workflow, we are running into questions around how such workflows intersect with established rituals, processes and artifacts that govern and frame the Open edX community. For example, how should product discovery work intersect with the OEP process? When should we be creating approach memos vs ADRs? How can we build channels and pathways for contribution for would-be contributors who may not have fluency necessary to navigate GH processes? It’d be great to brainstorm ideas with perspectives from both product and engineering in the room.

@Jenna Makowski @Feanil Patel

@Andrés González @Esteban Etcheverry

Accessibility, Inclusion, Universal Design for Learning

As accessibility and inclusion become increasingly important, how can we use text-to-speech technology and Universal Design for Learning (UDL) concepts to support diverse learner populations. Are these technologies only about accessibility, or does a rising tide float all boats?

@Amy Foxwell

Keeping the installations up to date

Being on the latest stable version has many advantages: latest security patches, bug fixes, new features, better performance, etc. However, there is a huge set of installations that are still in Koa, Juniper, Ironwood or even older. What prevents system admins to upgrade?

• Deprecation process, if upgrading will cause loosing useful features or require effort to change

• Difficult, unclear or nonexistent upgrade path (step by step instructions)

• Deep customizations, with changes hard to merge to newer branches

• Lack of information encouraging to upgrade

• Etc.

What can we do to encourage the community to have the platform in the latest version at all times?

@Andrés González