Enhance Core Contributor Onboarding
Open edX Handbook
+1 to the handbook, definitely feel free to pick up this proposal @cassie
Imho you don’t need to constrain the handbook specifically to the core contributor program, even if it would of course be used most by the core contributors. It can be potentially for all types of contributors and community members – we have talked about creating an Open edX Handbook for a while.
We can focus the content creation in the first iteration of the Open edX Handbook to the core contributor program - but this could be one (or several) chapter(s), but in the future other parts of the projects could add their own section if people find it useful?
Also something to consider: to not conflict with other medium that describe how things work, like OEPs or ADRs, it might make sense to include or reference parts or all of some of those documents in the handbook.
Last bit: it might be better to have the handbook on a github repository - this allows people to submit changes as formal pull requests, and other people to review the change before it’s enacted.
Additional proposal: Opening the core contributor onboarding courses
We have a great base for the onboarding course, but it needs to keep being iterated on. For this, the course needs to be properly open source, accessible and easy to contribute to. That would allow more people to push changes, like community members who implement a change or notice an issue, or new core contributors while they go through the course.
Currently, the course content is not publicly visible and enrollment is closed (only on invitation) and I don’t believe the source of the course is publicly accessible either. There are reasons for this (not confusing people who would come across instructions meant for core contributors, and some legal hurdles), but we lose a lot of the benefits of open source collaboration because of this, so we should approach it differently:
- add a warning that the courses are for core contributors on all pages, and solve the legal hurdles – which in turns would allow us to:
- make the course visible publicly
- open up to spontaneous contributions, without having legal steps before being able to open a PR or suggest a change: publish the courses source on github and open it for merge requests (or find another way to achieve those goals).
Improve Collaboration, Communication & Reporting
Evaluate and define communication tool roles
+1 to doing this. Ideally along with this other proposal (kept separate because much more likely to be contentious:)
Ensure that Working Group names are self-explanatory
I agree that this can be simply mentioned in the handbook. For the contributors coordination working group in particular, I would put forward this proposal:
Additional proposal: Clarify the name of the working group used to discuss community-wide issues
We need to make it clearer where community members can bring up topics of governance that span over multiple working groups - like contributor programs, community issue, or any project-wide governance topic. Since what is currently called the Contributor Coordination Working Group has long served that role at the working group level, renaming it the Governance Working Group (and identical meeting name) would make this clear to people who aren’t familiar with the meeting contents. It could then help unblocking issues, or for larger topic like now, help organize summits and community-wide consultations, or liaise with the TOC as needed.
Additional proposal: Consolidate communication tools that overlap in features, keeping the open source ones
Given the strong agreement in favor of reducing the number of tools vs streamlining them (80-15%!), we should seriously look at merging some of them. It will be difficult to implement, because merging tools means removing some tools and that always brings up opposition, but we would definitely benefit from consolidating our communication tools.
Given the survey answers about preferring open source tools to proprietary ones for communication, we could consolidate tools that overlap in features, keeping the open source ones.
What I would suggest here is to move from the synchronous & proprietary tools to the async and/or open source tools:
- Move Slack conversations to the forum (include the discourse chat module there if necessary)
- Move the atlassian wiki to discourse too (use wiki posts & categories/tags to organize it)
This would remove 2 proprietary tools, and regroup on the forum-type discussions currently happening in 3 different places, opting for the tool which is preferred by the respondents, is async-first and open source.
Additional proposal: Improving the way we do core sprints - Open edX Handook PR?
The way we do core contributors sprints currently is not widely understood, nor very visible. We might need to integrate more of the usual tools involved in sprints: tickets, boards, sprint planning & retro. We do some of that, but once the current way we do sprints is properly explained in the
Additional proposal: Merge the Contributors Meetup Async Update and the Core Contributor Check-in
Focusing on valuable content, less often and with more of a presentation effort - do we keep the idea of a newsletter format? Imho trying to automate it further would accentuate the boring aspects - if we can do a nice newsletter with interesting content and news about the other core contributors, that would be more interesting to read? It’s more work, but getting the community to become more self-aware isn’t going to be simple. We could try it a few times as an experiment, and see what the reactions are?
Improve Fulfilling Commitments and Planning Processes
Additional proposal: Review core contributor contributions volumes for each organization & assign alumni roles
This is already in the core contributor OEP, and has recently been updated to an annual review - so this seems already in the works. But it is important to keep contributors status up to date, both for the project and the contributors themselves. It can be guilting to carry a responsibility that we are not able to fulfill. And it’s fairer for everyone when the commitments and titles match the actual work.
Additional proposal: Require Open edX partner organizations to commit maintainer and core contributor time
This comes as a sister proposal to the previous one - to ensure the core contributors have enough time dedicated by our respective organizations to maintain and improve the project, we all need to chip in a little. Maybe require a minimum number of maintainers or core contributor hours per revenue bracket, to adapt it to the size of the companies?
Improve Review Processes
Here I will be curious what @tikr and @kshitij will come up with 
Assignment
So far we have only assigned one proposal, the handbook which you picked up @cassie. I’d like to have at least the list of proposals above assigned, so I’ll pick up a few:
- Opening the core contributor onboarding courses
- Clarify the name of the working group used to discuss community-wide issues
- Consolidate communication tools that overlap in features, keeping the open source ones
- Require Open edX partner organizations to commit maintainer and core contributor time
Note that not everything will be accepted, so it’s fine to pick up more than you would achieve on your own - right now it’s only about getting a proposal submitted and discussed. We can take the time to work on what gets accepted afterwards, sequentially or splitting up the work among us afterwards.
Also keep in mind that I will need to be able to review the proposals before Thursday next week, as I’ll be off from Friday until the submission deadline.