This is the retrospective for the most recent Core Contributor (CC) sprint from June 24th - July 8th:
1. Calls/Offers for Help
This is what the core team needs help on now. Note that anyone can help – you don’t need to be a Core Contributor (yet!) for that. The question was “Is there anything where you could use help from others? Or that you would like to collaborate on?”
@maria - let’s work together on getting some of the course stuff defined that you were asking about
Sarina Canelake
2. What went well?
What went well these last two weeks / sprint?
Made progress across diverse initiatives.
Edward Edward
There are a lot of documentation improvements going on!!!
Maria Grimaldi
Coordination with edX/2U is getting smoother Discussions about the CC nomination process were productive, and helped clarify our policies.
Jill Vogel
We’re starting to make better connections between the product working group and the BTR working group. I’m looking forward to having more and better forward-looking information feeding into the release process.
Peter Pinch
Many governance topics moving forward! And good discussions and advances on them recently.
Xavier Antoviaque
3. Improvements and Blockers?
Did you experience any blockers or have suggestions for improvements?
Retrospective - Improvements
User
Improvement: I completely forgot to attend the virtual community event :cries:. From now on, I’ll block my calendar so this doesn’t happen again.
Maria Grimaldi
The backporting process is pretty convoluted, especially when it involves adding a patch to Tutor.
Kyle McCormick
We seem to have run into a lot of issues with nutmeg and database configurations. Perhaps this is inevitable with the migration from mongodb to mysql, and the fact that our table character sets, etc. may not be in sync with edx.org. I am concerned however that tutor users have reported similar issues, e.g. Emoji in subsection title not supported since Nutmeg - #3 by pdpinch
Peter Pinch
The migration process from older versions, especially from native to Tutor, is complex and problematic
Andrés González
Retrospective - Blockers
My other client work is taking up all my brain space at the moment, so I’ve found it hard to make time for CC.
Jill Vogel
4. Hours contributed
The total reported hours contributed for the latest sprint (14 days): 289.5 hours
User
Hours Contributed This Sprint
Edward Edward
60
Kyle McCormick
60
Andrés González
50
Sarina Canelake
20
Xavier Antoviaque
17.25
Gabriel D’Amours
12.75
Braden MacDonald
12
Igor Degtiarov
12
Juan Montoya
12
Felipe Montoya
10
Maria Grimaldi
8
Peter Pinch
6
Dean Jay Mathew
5
Pierre Mailhot
3
Jill Vogel
1.5
The totals of the hours reported in the last thirteen (13) sprints: 2421.22 hours
Feanil Patel
222
Andrés González
197
Sarina Canelake
186.25
Piotr Surowiec
170
Kyle McCormick
150
Xavier Antoviaque
132.4
Edward Edward
130
Gabriel D’Amours
112.25
Ali Hugo
111.82
Felipe Montoya
95
Maria Grimaldi
92.75
Zia Fazal
88
Peter Pinch
81
Ghassan Maslamani
80.25
Braden MacDonald
64
Igor Degtiarov
55
Dean Jay Mathew
50
Kshitij Sobti
41
Adolfo Brandes
40
David Ormsbee
40
Pierre Mailhot
39.25
Juan Camilo Montoya
38
Jillian Vogel
35
Matjaz Gregoric
29
Giovanni Cimolin
28
Sofiane Bebert
20
Jhony Avella
16
Usman Khalid
13
Juan Montoya
12
Nizar Mahmoud
10
Steffania Trabucchi
10
Omar Al-Ithawi
7.75
Esteban Etcheverry
7
Nicole Kessler
7
Ilaria Botti
4
JayRam Nai
4
Jill Vogel
1.5
Chintan Joshi
1
Stefania Trabucchi
0
5. Check-ins
Congratulations to Gabriel, Kyle and Andres for crossing the 100 hours mark!
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.
@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.
First I want to cleaify that are two issues that are related but are different.
Peer depedecny issue: there are peer depednecy in some MFEs hence PR mentioned and this in accont MFE. This might or might be realted to have a consistent dependcies in MFEs. i.e. we might a consistant wrong version of library in all MFEs.
Secondly having a consitant versions for shared libraires is an issue which I initailly started to research how to resolve because I wanted to create a monorepo version of common MFEs Why I wanted to create a monorepo, you can see the repo link below also relevant disccusion here.
I’d like to understand why the various frontend packages…
I didn’t actually write this, but I have been wondering the same thing so I’m glad someone brought it up. Thanks for sharing mfes-mono @ghassan , I am interested to hear what you learn.