As part of planning for the Koa release, there are specific tasks that have to get done, like creating branches, making new chapters in the docs, making announcements, and so on. In the past, I have done these tasks, but as part of shifting ownership to the working group, we can talk about how they get done for Koa.
Some specifics of the tasks are in the Process to Create an Open edX Release wiki page, though it is a little out-of-date, and sketchy in some places.
@nedbat Thanks for getting this discussing started! Maybe we could start by looking at tasks you’re wanting to pass on first? For Juniper, the testing and bugfixing was split between members of the release workgroup. What else would be useful to handle similarly? They could be turned into tasks, and assigned at the same time?
FYI, on OpenCraft’s side it will be @0x29a who will be handling Koa - don’t hesitate to pass on work to us through him. @0x29a is there anything you would like to take on from in https://openedx.atlassian.net/wiki/spaces/COMM/pages/19662426/Process+to+Create+an+Open+edX+Release ?
The main things I could use help with are:
I think it could be useful for people to be more familiar with the mechanical steps that go into the release, but those are mostly automated anyway.
It looks like all those steps are currently being addressed by the BTR working group: issues are collected in the working group board, assigned to volunteers during the weekly meetup and addressed by them (hopefully). Am I missing something?
No, I didn’t mean to imply that these weren’t getting done. I was speaking generally about the types of things that have to get done during a release, and where people can help.
@nedbat Thanks for getting those listed! Yes, I think last time we already did have tasks for the four first points – but on the 5th point, about collecting and editing information, there are things like cutting branches or making the blog post announcements that currently require to be from edX no? Could we break down this point, to list what’s involved? Let me know if this isn’t useful though - my goal is to identify additional points on which we could help, not to get in the way.
FYI, on our side it’s useful to be able to do some planning/assignation async outside of the synchronous meetings. Everyone involved on our side can’t always participate to the relevant meetings, due to timezone or other engagements (or calendar invites which don’t show up in Google calendar like for me today 
). It’s useful to have a preparatory grooming/refinement of the backlog, between meetings - the more is done before the meeting, the more it can be left to discuss other points?
Sorry for the late answer, @antoviaque.
Work on preparing the release now take place in BTR working group board and I already assigned myself to BTR-28 and BTR-5.
I made the Koa master branches. In the interest of spreading the knowledge, here’s what I did:
First, I made a test branch called nedbat/test/k.1112b. A few repos had special branches pre-made to keep them on Elasticsearch 1.5. The tag_release tool can be told to override the reference for particular branches:
$ tag_release --doit --branch --skip-repo "*-internal" --override edx/cs_comments_service nedbat/for-koa --override edx/edx-notes-api nedbat/for-koa nedbat/test/k.1112b
I installed nedbat/test/k.1112b, and saw that it was successful. Time to make real master branches, at the same commits as nedbat/test/k.1112b.
$ tag_release --doit --branch --skip-repo "*-internal" --override-ref nedbat/test/k.1112b open-release/koa.master
After making two commits on the koa.master branch (to mark it as Koa and to create new Transifex projects), it’s time to create the open-release/koa.test01 branch:
$ tag_release --doit --branch --skip-invalid --search-branch open-release/koa.master --override-ref open-release/koa.master open-release/koa.test01
(Looking at these commands now, they have a mix of “skip-repo” and “skip-invalid” that doesn’t really have a reason.)