OpenCraft Core Contributors Call for Proposals: Summit to Enhance the Core Contributor Experience

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 - :warning: 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
  • An Open edX handbook - @cassie
  • Evaluate & Define Roles of Communication Tools - @Ali
  • Mega-proposal to Improve Review Processes - @tikr and @kshitij
    • 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.
  • Integrate working groups with CC nomination process - @navin will you propose this?
  • utilize GitHub’s CODEOWNERS file to automatically notify reviewers on pull requests - covered in Tim/Kshitij’s mega-proposal
  • Automated reporting of code/docs contributions and/or Organization-level reporting of github contributions - @jill to propose

Outside of OpenCraft:

3 Likes

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.

Single Responsibility Proposal - and automated escalation

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.)

1 Like

@braden Yes, as well as improving review process by using CODEOWNERS file.

Proposal doc

2 Likes

@braden Interesting! Definining a clear escalation path would be quite helpful I think.

How would we choose the reviewer to assign initially?

1 Like

I think the same. @antoviaque I feel that a detailed proposal can be written on this topic.

1 Like

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.

1 Like

@braden That makes sense, and for an unmaintained repo I guess it would continue to be the responsibility of the OSPR manager that handles the repo.

@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 :slight_smile:

2 Likes

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?

Proposal 1

I have posted this proposal on the wiki: Continuing to Iterate After The Summit: A Governance Working Group

Reviews welcomed, comment directly inline there.

Proposal 2

And I have posted that one too: Open edX Partners As Maintainers

Same thing, reviews there welcomed.

Proposal 3

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.

@jill @Agrendalath @kshitij @gabriel @Ali @mtyaka @pooja @farhaan @Ali @cassie @navin @gabor @ChrisChV Would someone else be willing (and have time) to take it on? If so, you just need to go post this document on the wiki before the end of the week:

2 Likes

@antoviaque I think this proposal should replace/merge into @Ali 's Evaluate & Define Roles of Communication Tools

What do you think @Ali ?

1 Like

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?

1 Like

@antoviaque That should work.

I’ve started to adjust the proposals. I’ll share them once I’ve finished updating them as per your suggestions above.