Conf BOF: Governance Topics?

[sarina (Sarina Canelake)]

Hi All,

I am starting this thread not to discuss this question, but rather to collect this question - and any you all might have - for an agenda for a “birds of a feather” (informal discussion) at the Open edX Conference.

Question from me:

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?

I look forward to a discussion of this question and please use this thread for listing out ones you’re curious about.

[antoviaque (Xavier Antoviaque (OpenCraft) - opencraft.com/help)]

@sarina Thanks for opening the list of topics to proposals! Here are some of the topics on my list for the discussions at the conference:

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?