Dec 21: Koa release retrospective meetup

Working Groups Build-Test-Release
#1

Hi gang! :woman_supervillain: :man_supervillain:

During our next meetup on 2020-12-21T16:00:00Z → 2020-12-21T17:00:00Z I’d like to work together on a retrospective of the Koa release and I’m asking you to prepare for the following questions:

  1. What did you like? What do you think worked well? What did we successfully achieve together? Please don’t be shy: you should include at least one personal achievement here.
  2. Why did you decide to participate in the release? (please expect me to ask “why” multiple times)
  3. What didn’t we do so well, and what could we have done to do better?

I’m explicitly tagging @nedbat, @BbrSofiane, @0x29a, @cmltaWt0, @Felipe, @blarghmatey, @morenol, @sambapete, @pdpinch, kmccormick in case you guys aren’t getting notifications for every new post in the BTR category. (you should :wink:)

See you then!

2 Likes
#2

I’m really looking forward to this discussion! I’m really pleased with what BTR accomplished for Koa, and want us to do even more for Lilac. Improving our process by examining how we are doing will be important to meet that goal.

Remember: the discussion should be about what the BTR group did (either collectively or individually). There are many things that would make our jobs easier, but we should focus on things that are in our control.

For example: time zones are confusing. We can’t change that. But maybe we can do something differently to deal with that confusion.

See you Monday!

#3

I am starting my end-of-year holiday vacations early this year. I will be out of the office starting on December 19th and until January 4th. I will do my best to try to attend the meeting on Monday.

#4

  • What did you like? What do you think worked well? What did we successfully achieve together?
    I liked the fact that there was broad community engagement in identifying and working through the issues that were of concern to operators of the Open edX platform. That provided a helpful amount of visibility into what to expect going into the Koa release and working through issues before they were made permanent.

  • Why did you decide to participate in the release? (please expect me to ask “why” multiple times)
    I participated in the release because at MIT Open Learning we are responsible for managing multiple installations of the platform. We also work to stay up to date with releases as they come available. Because of the timing for the Koa release being close to our seasonal upgrade window I was incentivized to help make sure that it was available at the target date so that I wouldn’t be left running Juniper for an additional semester.

  • What didn’t we do so well, and what could we have done to do better?
    I think that one thing that we can do going forward which will help as more people get involved is to draft up a set of expectations or guidelines for involvement in the working group. In particular, standardizing on what the target deployment method will be (thinking of the times that an issue was raised that wasn’t material to the native install method), what the preferred avenues of communication are (wasn’t an issue, but will help newcomers), etc.

2 Likes
#5

What did you like? What do you think worked well? What did we successfully achieve together?

Collaboration is key. Tobias summed it up perfectly. I also believe personal achievement should not be a thing here as it is a collaborative project.

Why did you decide to participate in the release? (please expect me to ask “why” multiple times)

EDUlib has been on board the Open edX train since late 2014, so just a little bit before the release of the first named/open release Aspen. We are a relatively small instance/provider compared to some of the major providers that are part of the group (OpenCraft, eduNEXT, Racoon Gang), but we do have our own fork. We like to keep up with current releases. We also do not want to be left behind and play catch up with new releases. Not being a developer, my contribution is more geared towards testing the native installation, “manual” testing of the release and regression testing of our local modifications to check if everything still work with the current release and if new parts of the code are properly translated. Running a multilingual site is quite different than running a unilingual site. I also find bugs… It’s mostly our contribution to the Open edX community. It also allows us to help people in Slack and Discourse when the new version is released and people have questions or problems.

What didn’t we do so well, and what could we have done to do better?

There are still a lot of people / organizations who have been part of the Open edX community for a long time that do not delegate anyone or participate in the BTR meetings. The same being true for the other working groups to be honest. Should we publicize our working groups more actively? How do we reach out to them? Most of the people or organizations participating in the BTR working group are people or organizations I’ve met way back in 2014 and 2015 at the first 2 Open edX Conferences in Boston. Maybe onboarding is difficult not just for developers but for testers too?

1 Like
#6

Hey everyone! I’ll be out of office all the next week and I wont be able to attend to the call. However I do leave my 2 cents here:

  1. What did you like? What do you think worked well? What did we successfully achieve together? Please don’t be shy: you should include at least one personal achievement here.

    I liked that we shipped on Dec 9th. It was our target, it was predictable and it was not easy, but we said we would do it and we did.
    I liked that we made the MFE deployments a possibility. It was announced as being part of juniper but in practice it was still lacking a lot of work that was only merged by koa.
    I think that having the preassure of time and the CC program worked well in favour of us merging the PRs that needed to be accepted and merge for the release to work.

  2. Why did you decide to participate in the release? (please expect me to ask “why” multiple times)

    I wanted to help make the release cadence something we can trust. I have for long being in the side that wants releases to be time based more than feature based.
    I also wanted to start pushing my organization to be more active in the BTR process and I thought that the way to lead that would be to participate in first person initially.

  3. What didn’t we do so well, and what could we have done to do better?

    From the moment we cut the beta branch to the moment we released I think not enough testing happened. I know at least we did not do enough testing in those dates and we need to get better at it.

#7

What did you like? What do you think worked well? What did we successfully achieve together?

  • We shipped Koa.
  • We shipped Koa when we said we would.
  • We had active participation at face-to-face meetings and online.
  • MFE deployment is much further along.
  • More decisions were handled by the group in Koa than in Juniper.
  • We’ve already started on next-gen installation discussions

Why did you decide to participate in the release?

  • To help produce the best community release we could.
  • (Also, It’s my job. :slight_smile: )

What didn’t we do so well, and what could we have done to do better?

  • I felt like activity happened right after the face-to-face meetings, but it was harder to make things happen at other times.
    • More face-to-face?
    • Async checkins on Slack?
  • Especially near the end of the cycle, I felt like I needed to do things quickly and so couldn’t be as collaborative as I would prefer.
    • Maybe it was OK?
    • maybe not?
  • I think the release process would be smoother if we could triage bug reports more quickly, to determine if they are something that needs fixing or not.
#8
  • What did you like? What do you think worked well? What did we successfully achieve together?

The community chose a date that worked for them, and we worked together to finish the work by that date. This involved identifying issues that needed to be fixed, identifying people to fix them and also identifying issues that would not be fixed.

  • Why did you decide to participate in the release? (please expect me to ask “why” multiple times)

MIT Open Learning has a relatively narrow window for updates twice a year. We really wanted to see this update get released in this timeframe. Because we were able to collectively come up with the release date, we finally had one that was aligned with our needs, so we were motivated and had the time free to contribute.

  • What didn’t we do so well, and what could we have done to do better?

Meeting face to face is hard, and it’s disappointing that we needed to meet face to face to keep work on track. I think we need a mechanism to make decisions that doesn’t depend on consensus amongst whoever showed up for a particular Zoom.

#9

What did you like? What do you think worked well? What did we successfully achieve together? Please don’t be shy: you should include at least one personal achievement here.

  • I liked that we were able to deliver on time.
  • I liked that members of the group were available to share their knowledge and experience.
  • Personally, I was able to contribute to a couple tickets and submit my first PRs.

Why did you decide to participate in the release? (please expect me to ask “why” multiple times)
At Dicey Tech, we’ve only started using Open edX about 2 years ago. Taking part in the release cycle was a way to:

  1. Learn from the community the ins and outs of running and developing open edX.

  2. Allow ourselves to be as close as possible to the latest release to benefit from the latest features of the platform.

What didn’t we do so well, and what could we have done to do better?

  • There was a period when testing the upgrade to ubuntu where it was hard to contribute until progress was shared in the configuration repo. For initiatives that require the input from a few people, we should start with a common way of sharing work/progress/fixes.
  • When someone takes on a ticket, they should commit to a date to provide an update on the ticket (personally something that I need to do better). Otherwise, other priorities can always creep up.
  • Testing the platform as a whole felt a bit too “exploratory”. For someone that’s new, it would be useful to have a starting point or some type of guidelines.
#10

What did you like? What do you think worked well? What did we successfully achieve together?

  • I’ve submitted my first PR. @BbrSofiane :metal:
  • We complete testing in time
  • Koa is great :sparkling_heart:

Why did you decide to participate in the release?

  • I want to be aware of any new features or fixes in the platform
  • I want to contribute to bug fixing since it’s will help vendors and my own company to provide a bug-free system
  • I feel it’s very important to make thing happens in time with a great outcome

What didn’t we do so well, and what could we have done to do better?

  • Installation procedure raised questions - it’s an opportunity to do it better next time
  • My contribution was small - next time I should do more in testing the installation and providing the fixes
  • Have a feeling that newcomers can be a bit confused about the process (it’s not bad but maybe should be documented)
1 Like
#11

What did you like? What do you think worked well? What did we successfully achieve together? Please don’t be shy: you should include at least one personal achievement here.

That’s my first experience in release preparation for such great software, and I was really excited and happy about being a part of a team which consists of leading professionals.

Also, we resolved many issues and shipped Koa in time :slight_smile:

Why did you decide to participate in the release? (please expect me to ask “why” multiple times)

Because we at OpenCraft are trying to give back to the community. Also, lot of our clients expressed desire to upgrade to a new version of Open edX, so that was a good opportunity to be aware of all changes / possible difficulties.

Speaking of myself, I like to think that I help to build truly important software.

What didn’t we do so well, and what could we have done to do better?

I think we need to be more open about BTR board existence, where everyone can report the issue or take some work.

Also, we at OpenCraft should have done necessary preparations earlier and deliver CI before actual release.

#12

See you in two minutes everyone! Please note that the zoom link has changed: Build/Test/Release Working Group Weekly Meetup
https://us02web.zoom.us/j/87102635068?pwd=c0dWSEl1ZlV4VFVFZUIvUDExSWdQZz09 (Meeting ID: 871 0263 5068 Password: btrwg )

#13

Here are the notes we took from the discussion: https://openedx.atlassian.net/wiki/spaces/COMM/pages/2175467618/2020-12-21+BTR+Koa+Retrospective

1 Like