This thread is kind of hard to follow so here’s my attempt to summarize the status:
Ideas for proposals:
Merge the Contributors Meetup Async Update and the Core Contributor Check-in - needs proposer. May overlap with Feanil’s proposal to radically simplify the check-in.
Review core contributor contributions volumes for each organization & assign alumni roles - maybe needs proposer but @antoviaque mentioned this “has recently been updated to an annual review - so this seems already in the works” and Feanil mentioned “Axim already has to reaffirm organizational and user commitments. Evaluating the level of commitment of a user as a part of this work is a natural extension.”
Opening the core contributor onboarding courses - @gabriel to propose
Clarify the name of the working group used to discuss community-wide issues - @antoviaque to propose
Require Open edX partner organizations to commit maintainer and core contributor time - @antoviaque to propose
Making it easier for PR authors (including but not limited to CCs) to manage their own PRs.
Making it easier for CCs to help with PR reviews.
Automating additional parts of the OSPR management process
“Improving the way we do core sprints”
@ChrisChV was interested, but @antoviaque pointed out this is touched on in @Ali 's Open edX handbook proposal. It’s just this one sentence though: “Detail the sprint process and outline expectations for each Core Contributor, including check-ins if necessary.” - seems like more could be proposed? Though we do some reporting and admin on a two-week cycle, there’s nothing in OEP-54 nor on the wiki about “sprints”.
personally I don’t think we should be doing formal sprints for CC program; prefer kanban or something less structured.
My own proposal has a lot of overlap with the things @tikr and @kshitij are proposing, but it’s a much more extreme version so I think it’s worth considering separately.
There is always a single person assigned responsibility for the next step of each PR.
The bot will post a reminder to the responsible person every ~two weeks
If the responsible person doesn’t reply for six weeks, and/or opts out, the PR is escalated and re-assigned to a more senior person (e.g. for frontend-app-learning the escalation path would look like: assigned reviewer → maintainer (Braden/Farhaan) → Frontend Committer (Brian, Adolfo, Braden, etc.) → Super Committer (Dave, Feanil, etc.)
I’m thinking that would be the responsibility of the maintainer. The maintainer doesn’t have to review incoming PRs themselves, but they should be able to prioritize them and figure out who would be a good reviewer.
@braden@ChrisChV Sounds good to me - establishing a good working workflow with everyone’s task apparent in a kanban board would already be a great step. As you know, I think sprints are better to plan and get things done, but we are clearly still far from this level of efficiency at the project level. So one thing at a time
This is a good point - we still need someone to take on this work. @cassie since you currently compile the core contributor checkin, you would be affected by this. Would you be willing to take on a proposal on this? The proposal itself could be minimal - like setting a next step of discussing with Natalia (and whoever else want to collaborate on it) to design a newsletter together?
There is a third proposal that I also wrote up, but I wouldn’t have time to take care of it given the two above, and I don’t want to submit it without having the means to enact it afterwards.
I think this needs more discovery since I don’t think Discourse is a good replacement for Wikis and has some key features missing even for Chat. I’ve commented on the proposal.
@jill@Ali@kshitij Maybe the two could be merged? Some of your proposal @Ali allow for more discovery, but we can also start experimenting with getting some of the content and discussions in discourse, while we look for additional alternatives?
@jill I agree that combining the two proposals makes sense, given how closely related they are.
However, @antoviaque, I remember you initially wanted to keep them separate since the proposal to “Consolidate communication tools that overlap in features, keeping the open source ones” might be more controversial. My concern is that merging it with my less contentious proposal could risk both being rejected (if the more controversial one raises objections). Do you think it’s safer to keep the proposals separate, or do you think we should just merge them?
@Ali A way around that would be to have two stages for your proposal: the first, centered around what you have in yours now, to discover more about usages, but adding the testing of solutions like Discourse chat & wiki (opening it to people to suggested alternatives). That initial vote should be uncontroversial, since it’s mostly discovery and documentation ? Then once the bulk of your proposal and the testing of proposed solutions are done, submit a proposal to merge the tools for a second vote, based on what was learned?
@antoviaque I have adjusted the proposals so that they work hand-in-hand. Please skim through them to see that you’re happy before I post them on the wiki:
Technically we are now past the deadline, so we shouldn’t be able to post additional ones… But I think if you post it anyway in the wiki with a note about the lateness to keep it explicit, I don’t see people objecting. It does mean it will be harder to refuse other late proposals, if any, though But that’s probably fine, too.
needs proposer. May overlap with Feanil’s proposal to radically simplify the check-in.
