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.
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:
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?