@Dean Thank you for the recap!
Follow-up from previous sprints
A follow-up on the topic of improving PR descriptions discussed at the Contributors meetup: this PR has been merged to move towards better descriptions on PRs:
Sprint’s checkins discussions
@kmccormick During the contributors meetup, @arbrandes indicated that this is caused by the current design, and that there are discussions on unifying dependencies, but there isn’t a clear answer yet. @ghassan has suggested and volunteered to do a discovery on this, and has a proof of concept that he will publish.
@pdpinch On this @dave offered to discuss with you. He has also provided a quick explanation of what CourseOutlines and CourseOverviews during the contributors meetup – it should be towards the end of yesterday’s recording (last 10-15 minutes) which will be published by @jalondonot at Open edX Contributors Meetup - #105 by jalondonot and Contributor's Meetup 2022-07-26 · Issue #69 · openedx/wg-coordination · GitHub in the coming days.
Definitely have a look at the TOC election draft! These are important discussions, which will impact the direction of the project.
Also worth looking at these two other collaboration & governance topics, which need feedback:
- Core contributor work scope definition: draft document up for review
- Kubernetes collaboration discussion: meeting scheduled for yesterday (Tuesday Jul 26th) - the recap and recordings of the meeting have been posted in that forum thread.
@mgmdi and @sarina will be discussing the plans for the onboarding courses.
For these three, there seem to be a common thread: the need to better support larger or more custom instances of Open edX, when they differ from the main Tutor use case. This is also something which we run into during the Kubernetes collaboration discussion. CC @kylesinlynn @pdpinch @Andres.Aulasneo @regis
@jill As long as the average number of hours matches the commitments and there is no deficit build up, I think we have generally agreed that it’s fine to have variations of availability over time – ie you can do more one month, and then less the next month. Some of the work might be guided by more specific requirements, for example with dealing with production/master issues, or the maintenance/upgrade of specific code bases, as maintainers.