Themed releases

[sirinoks]

So far our releases are just combinations of isses and PRs that people wanted to work on without much structure to it. However, even though our releases seemt to last the same amount of time, they are not if fact equal! Let me provide examples and you'll get what I mean.

Let's look at the Sheriffs + Releases table

Week	Date	Release
1	Jan 10	2.5
2	Jan 17	2.5
3	Jan 24	2.5
4	Jan 31	2.6
5	Feb 7	2.6
6	Feb 14	2.7
7	Feb 21	2.7
Study Week	Feb 28	2.8
8	Mar 7	2.8
9	Mar 14	2.8
10	Mar 21	2.9
11	Mar 28	2.9
12	Apr 4	3.0-alpha
13	Apr 11	3.0-alpha
14	Apr 18	3.0

What do we see?

1. First week has a lot of time. Makes sense, new people incoming, we are getting used to the course.
2. There are two busy times in college. Midterms and finals. It would make sense to have reduced load for this course during those times, since people will be already busy with their exams.
3. There is a Study week. It might count as an extra week, however can't be fully considered as one because of the midterms. We might want to use that somehow.
4. We can roughly divide the semester into two parts: before and after study week.
5. There is an alpha and a separate final release.

Here are some of my ideas of what we can do about this information.

1. Have a little checklist for the first week (already somewhat exists) that would help newcomers get used to the project. There is an email and a starting page that tells a lot of information. However, there were a couple things that I was missing when I joined.

• Firstly, I needed a reminder of squash/rebase/test PR etc. The process many of us will do countless times after, we should have a practice for those things, perhaps a live demonstration during the first week, or even better - a practice PR. I know we did it in the previous open source course, but for those that have bad memory (me) and some that skipped a year it might be a good reminder.
• Secondly, Telescope overview. That is something I am working on myself. Remember this thing? Yes, I want to leave something like that for future generations.
• Thirdly, communication with project elders. There are still people that have completed the course, but are active in Telescope. Many of them are aware of the project's structure and hold valuable knowledge. For example, I will need someone to take my place in managing projects once I finish the course. I would like there to perhaps be an event (a teams meeting?) that would be basically about older generation telescopers passing on their knowledge to the newer one.

2. Have a theme during the exam times that doesn't require as much coding within deadlines. Schedule larger issues for some other releases.

3. Study week to me sounds like reasearch time. It is an open ended task that can include a lot or a little effort, based on how deep you want to go. A reasearch task can't really have you stuck on a single bug, getting you stressed about not making it within your deadline. My next point will also support why it is a good idea to do reasearch around study week.

4. Having two major time sections in the course, logically it would make sense that there is no point to start new concepts towards the end. Because that leaves very little time to actually act on the research and implement the new ideas. If an idea gets researched and left halfway, it will likely get abandoned, since people working on them will no longer be in the course. Therefore, we shouldn't start new large ideas towards the end of the semester. The best time for new ideas would be the first half (before study week). Study week would be the optimal time to have most research done because of its nature, while let's say, Release 2.8 would be the last cutting off point for research and new ideas.

5. I would imagine, a final release should have no bugs. A release should be stable. That makes me guess the last week would be about finishing PRs, fixing bugs, testing and polishing. Therefore, an alpha should have all the major ideas added and working, so that there is still time to make it look pretty.

Therefore, themes

Week	Date	Release	Theme
1	Jan 10	2.5	Discovery
2	Jan 17	2.5	Discovery
3	Jan 24	2.5	Discovery
4	Jan 31	2.6	?
5	Feb 7	2.6	?
6	Feb 14	2.7	Research + new ideas
7	Feb 21	2.7	Research + new ideas
Study Week	Feb 28	2.8	Research + new ideas
8	Mar 7	2.8	Research + new ideas last call
9	Mar 14	2.8	Research + new ideas last call
10	Mar 21	2.9	Implementation
11	Mar 28	2.9	Implementation
12	Apr 4	3.0-alpha	Implementation that works
13	Apr 11	3.0-alpha	Implementation that works
14	Apr 18	3.0	Bugfixes, PR reviews, Polishing

Feedback

Now, this just my rough proposition. I definitely think we can have more concrete themes for single weeks, such as Testing, or New frameworks, perhaps Picking up abandoned issues. Themes should bring excitement for developers and perhaps involve people into things they never before thought of. It would be on Sheriffs to follow themes, or make their own. Some would prefer to have a stable regular week, while others want to focus on a single task.

So yeah, let me know what you think!

[humphd]

@sirinoks given that you're sheriff next week with @aserputov, it might make sense to have this discussion be the focus of the Tuesday planning meeting. You could lead a team discussion to try and figure out what our major themes/project areas actually are. At this stage, I think the team has a better sense of what they are doing for the coming weeks, so we could do more planning. I think it dovetails nicely with your docs/projects/themes ideas.

[cindyorangis]

Thirdly, communication with project elders. There are still people that have completed the course, but are active in Telescope. Many of them are aware of the project's structure and hold valuable knowledge. For example, I will need someone to take my place in managing projects once I finish the course. I would like there to perhaps be an event (a teams meeting?) that would be basically about older generation telescopers passing on their knowledge to the newer one.

"elders"
shakes cane
You're gonna be an elder in like 3 months.

But really, with a mindset like this, future Telescopers will inherit something awesome because you had them in mind the entire time and you don't even know who they will be. Telescope gets bigger and bigger after each iteration, this adds so much more complexity. Future Telescopers will be so glad that someone is trying to make everything easier to understand and get started with.

2. Have a theme during the exam times that doesn't require as much coding within deadlines. Schedule larger issues for some other releases.

It's tough to schedule things during exam time and study week because as you said, you can expect people to be busy. I think coding or participating in meetings should be optional during study week. Ofc if there's enough people interested in doing something in this timeframe then plan something with them...

3. Study week to me sounds like reasearch time.

Wow, some of you guys take no time to slack off, eh? XD @humphd took his first vacation in like 15 years during Telescope 0.5-1.0 and the team got like nothing done. Boy was he mad...

4. Therefore, we shouldn't start new large ideas towards the end of the semester. The best time for new ideas would be the first half.

Agreed. Any new features implemented in the first half will need maintenance done in the second half so that it will be stable in 3.0

5. I would imagine, a final release should have no bugs

There will always be bugs so we actually just pass on the bugs to the future Telescopers. The best thing to do is identify bugs in issues so at least people know about them.

Also, I wouldn't wait until 3.0 to fix bugs. That should be done way earlier. 3.0 should be stable enough that you can walk off and @humphd won't be left with bugs up to his neck and crying by himself. 3.0-alpha should be treated as a major release so if anything goes wrong, you have a one-week window to fix it.

Week	Date	Release	Theme
1	Jan 10	2.5	Discovery
2	Jan 17	2.5	Discovery
3	Jan 24	2.5	Discovery
4	Jan 31	2.6	Implement new ideas/features, clean up new/existing bugs, review PRs
5	Feb 7	2.6	Implement new ideas/features, clean up new/existing bugs, review PRs
6	Feb 14	2.7	Implement new ideas/features, clean up new/existing bugs, review PRs
7	Feb 21	2.7	Implement new ideas/features, clean up new/existing bugs, review PRs
Study Week	Feb 28	2.8
8	Mar 7	2.8	Implement existing ideas/features, clean up new/existing bugs, review PRs
9	Mar 14	2.8	Implement existing ideas/features, clean up new/existing bugs, review PRs
10	Mar 21	2.9	Firefighting?
11	Mar 28	2.9	Firefighting?
12	Apr 4	3.0-alpha	Any incomplete features will be pruned from project. Welcome to resurrect incomplete features after 3.0
13	Apr 11	3.0-alpha	Any incomplete features will be pruned from project. Welcome to resurrect incomplete features after 3.0
14	Apr 18	3.0	Final release. Party. Celebrate

Firefighting: You may find that the many features that you're adding this semester need a lot more work than what you had initially planned. You won't really know until you get there but what you can do is plan a time when this could be addressed. You don't want to plan and layout a roadmap for a release then later squeeze bug fixes into it. Always leave room for unplanned work such as bug fixes, unexpected problems after a pull request was merged into master, etc. It doesn't have to be in 2.9 because sometimes, it will make sense to do it earlier when you find that you're being overwhelmed with bugs.

[humphd]

I agree with the idea that features need a long time to stabilize on master. We land some PR, then find 3 bugs that have to get fixed, meanwhile more bits of the feature come in, we learn more about it, change the approach, etc.

Landing features should be incremental and done over a lot of releases. However, we can think about having larger chunks of the team focused on particular releases. For example, we might need a bunch of Supabase work done to support the React Native front-end, so we might all chip in with this work on 2.x.

The down side of this, in my experience, is that it's really hard to engage everyone on a subset of our features. Imagine if I said, "we're all focusing on React this release!" Based on your blog post this week @sirinoks, it's clear you wouldn't be happy.

So I think the themed release concept is good, but it needs to be thought through so we don't exclude people who need to focus in different parts of the tree.

A big software project is actually easier to work on than a small one, since there are so many separate areas that need attention, and you don't have to work on everything (unless you're me).

[cindyorangis]

@sirinoks I suddenly remembered we have this doc. It should help you remember how to git again

[sirinoks]

#2801 Should be done during study week, since that will be the time when all the work on issues is paused.

[humphd]

I think this can get closed, @sirinoks?

[sirinoks]

I will turn this into a wiki page

[sirinoks]

Wiki page done, this is getting closed now.