Completed issues

There's a lot to go over. Let's start with things I specifically did.

Project description

Firstly, something I decided to take upon myself to complete, as time kept going and it kept staying incomplete. The Supabase project description. Basically, take the info from the existing docs and rewrite it in a certain format. Before we leave Telescope to the next people, I want to make sure all projects have proper descriptions so people don't get lost.

SSO service documentation

As a part of the larger REST API documentation issue, I decided to complete all things I can. Since the recording describing how SSO service basically works was available, all that was left - to write it down and format it. I also know that there were more things to it that I couldn't gather from the said recording. I have decided to add those as additional issues, while shipping at least the main idea of how it works.

There is also this nice comment that collects information on SSO stuff, you might want to check it out.

Status service documentation

Another part of the big REST API documentation issue. I was told Status was not difficult to figure out, so I took it as well. It turned out to actually not be that bad. The dashboard area seemed like it had more to it, but... it turned out to be pretty simple. I think there is a lot more we can do with it. Or, probably, not we, but the next batch of students to come.

Docusaurus home page

This was supposed to be a more interactive and cool visual, but in the end, there turned out to not be enough time. Making things look fancy isn't as important as making things make sense. I decided to put my resources into documentation, especially that REST API one that we had for so long. Besides, I did get stuck on trying to make the animation I want work.

Perhaps, I should file an issue to improve my SVGs with animation. I also thought about how easy it was for me to create such simplistic static art. It wouldn't have to be a 16:9 scenery, but perhaps some smaller elements or parts that can be later placed here and there, and maybe animated in the future. I just want to give people toys they can then play with and put all around the website. I'm sure they will find a nice place for them.

I also decided to leave some basic level issues fixing some of the formatting. Since the next active semester to work on this would be hacktoberfest students, I know they will need some good first issues.

Merging the two About us versions

Now, this one I want to note, I didn't actually do. I realized it wasn't as simple as I first thought, outlined the steps to be done, and then asked for someone else with more experience with React to take it on. And someone did!

Issues created

As mentioned, I have created some issues myself, mostly simple ones for people to get used to the process. Here are they:

• Removing the tutorial panel from docusaurus home page
• (Didn't file it myself, but did decide to make one in my PR) Making the SVG art responsive
• SSO doc - SAML-2
• SSO doc - new functionality
• SSO doc - supabase
• Should add later? Animating the SVG home page
• Will be added Project keeper role hand off

Managing

I was one of the sheriffs of the last week. The most fun time! Well, not as fun as somewhere in the middle, where I would also get to communicate about people's progress and make priority lists... But still! I know it's a very important week and I know it is a tough one. Things need to be under control and things need to be done right. That's why I signed myself up for this - I like and can be on top of things. I'm happy I did.

I did a lot of maintenance steps this week, especially towards the end of it.

Meetings

We only had the one meeting this week. It wasn't an 8 am one! I set a time for 2pm on Wednesday for out last triage. Seemed like a good all around time. Many people were missing, but we also had a lot of engagement from those who did attend. This was the outline for the meeting:

• Have PRs done by today!

• Tomorrow at 2pm release, might shift to later if needed

• Regular triage

• Priorities

• People's last input

• Anything you want to add

We started with a simple going-over-issues-PRs, asking what's up with those... But this time, a little differently. This time it was important to ditch things that aren't important/too time-consuming. We had people that were free to pick up what's important and we also had people that had too much on their plate. It wasn't a simple "will you get it done?" anymore, but managing people's workload and dividing some tasks into smaller versions of the same tasks. We ditched a bunch of things. We rearranged tasks to other people. I, myself, changed my focus from visual docusaurus stuff to completing REST API docs. Tue had a lot to do, but somehow he was the only one who could. Well, I think he still had some help, but he definitely had the most on his plate for this week. Gold star, if we got one.

I have then introduced the idea of leaving information behind for the next students to come. The simplest solution I had for this was to just include some info in the blog post. Everyone has to write the blog post, so might as well talk about things I want to know. Better though - to get in a call with me, so I can ask about details.

What did I want people to tell me? Basically, an overview of the area of Telescope they've been working on. I need to compile a complete overview of Telescope, and I am not familiar with all of its areas. Therefore, I need to collect that information.

Secondly, I want to pass on people's advice. I will definitely share mine, but I'm sure I'm not the only one. Especially, when it's about some other technology someone specializes in.

In the end, we talked about our experience with this course. I announced my gratitude for numerous times I required help with git. People enjoyed their Telescope experience. I know I definitely did.

Setting deadlines

For releases, especially for the final week, it is extremely important to have that line drawn. It has to be simple for people to follow, since during finals nobody has time to read all the updates. I used Teams calendar to set those meetings way ahead of time, since it shows up right away for people. I think my timing for the triage was good, 2pm Wednesday - chill, decent time.

The release, however, wasn't that smooth. I first set it to Thursday 2pm, but as the time came closer to it, it became clear we can't land many things we wanted, specifically the most important ones. My instinct was to give people more time, to make sure there would be nothing else going on. Saturday I thought. However, that idea wasn't popular. People were insistent on Friday, so there it was - Firday 4 pm - 3.0 release. I did most of PR reviews and my own PRs at night between Thursday and Friday. I haven't slept yet, it is currently 7pm of Friday. We are still doing the release. Things are breaking.

Reviews

I have done the best I can with reviews, however, there were many that I couldn't test. I'm not able to do docker things with my version of windows, so I had to ping other people to do it instead. I did review the boring docs though! There were also many technologies I wasn't qualified to review because of my lack of skills.

Labels

We had a lot of PRs. We needed to have reviews ready, so to make it the simplest experience for people, I kept assigning difficulty and area labels onto PRs. I also assigned some to issues, however, I haven't gone through all of them yet. I do plan to.

Annoying people

Especially towards the end I really kept pinging people for updates on things. Some PRs had no instructions. Some were drafts, but were still approved. Many were just not clear. So, those people had to be pinged. At some points, there would be no response, and a decision had to be made based on the unclear information we had.

Release

The group began reviewing and collaborating a few hours before the release meeting time. They really made those PRs just in time, so we proceeded to work on the release with everyone ready and on it. As soon as we started - things started breaking. There was a thing about ngnix, a thing about a conflict of PRs, some files were not properly added, something something staging... The release wasn't formed properly because it produced errors, so you can see THERE IS NO 3.0.0 IN RELEASES!. Something something unit tests. Then SSO was broken. Then... uuh.. The database broke. The final problem was...

Parser is broken! No new posts will be shown on it x_x. So, for new posts you can look at staging. Unfortunate. I have been up since yesterday, others that were in the meeting were pretty exhausted as well. We decided to go back at it tomorrow with fresh brains. Not that I had any clue why things didn't work...

Cleanup

As this is the end of the semester, I want to leave the repository in its best state I can. I also decided to stay around after it's officially over, at least for the near future. I will have a co-op next semester, so I don't know how much time I will have left for Telescope. Either way, I have some things planned to contribute to the general improvement of quality and organization.

Sidebar

Sidebar updates! I haven't always been updating it, I'm sorry. But now I have, with some new things on there. At the very least it needs to be updated at the very end of the semester. It can be left untouched for some time since then.

Priorities

I have done this before as a sheriff. I went through all the issues and sorted them based on how important they are. I want to do a similar thing before I leave, as we have abandoned some unfinished business that was quite important.

Another big part of this process is to figure out what the issues are even about. There is a category for this specifically, named "talk". Means, this issue needs to be discussed, as it is unclear. Why is this important? Because if it's been there for ages and is still unclear to us, it will likely be left untouched by future students as well. Once we do figure out what an unknown thing is about, we can either close it, or improve its issue description. Maybe leave some comments explaining what we found out. So that people of the future don't waste time doing the exact same thing and have a better idea of what's going on.

How do I actually plan to do it? I just want to get into a call with a bunch of people, where we would go over the issues one by one. It would have to be after the semester is over, so perhaps we won't get many people attending. However, hopefully, David will be there, as he is the one mostly creating issues, or at least the one aware of them. I have added all issues to this project board so far, so a starting point has been set.

Themed releases

There has been a proposal this semester, my idea to do "themed releases". The idea was to make weekly meetings and tasks a little more fun and meaningful, as well as add some more structure to our process. I mean, you can just read the issue itself.

As we have experimented with this concept this semester, it brought some results. I don't want to lose this information and approach, so I wanted to make it into some sort of a static guide/advice kind of thing. So, I made it into a wiki page.

I am also unsure why we have some things on wiki pages, some in README's and some on docusaurus. Perhaps we need a better, more structured system for this. Oh, hopefully, I won't forget to address it!

How to be a Project keeper

I have made a draft on this document a long time ago. Now that there's not much time left, I need to make sure it's done. I did some final changes, and now it's complete.

Being a Project keeper is a concept I thought I try to make stick. It's basically what I have been doing, or wanted to do within Telescope. And now that I might have less time on my hands, I don't want these things to get lost and abandoned. I want my work to live on. There are many things that I think just make the developer experience better and should be done. So, I have created this concept to be passed on and, hopefully, picked up by someone next year.

Hacktoberfest issues

Something I know has to be done eventually, by someone, is to prepare Telescope for hacktoberfest. Firstly, labels need to be assigned. "good first issue", or just generally having appropriate area labels to things. Secondly, the issues themselves need to be decent. Clear, understandable by noobs, doable.

As I am planning to do that priority list, as I will be going over every issue out there, I will be as well assigning appropriate labels and improving the issue description. It should work great to improve developer experience for hacktoberfest.

Videos planned

As my tribute to the next generation, I want to leave behind information. And I know .md files are alright, blog posts are okay, but videos - oh, videos are just better. You put them on x2 speed, you get to relax and follow... It's much more common for me to try and read a page and realize I haven't even processed what I just read - it's all blank as compared to watching a video and not remembering anything about it. Sure, you can still blank out on a video, but it's more engaging than text. Either way, I know I can make videos, so I will. They won't be like those tutorial videos though. I can edit things and make them extremely time effective, but I don't want to. There's a reason I do streams and not youtube videos.

Advice

I am not yet sure if I want this to be a single video, or separate ones. I don't want to make it too polished and time-consuming to make, instead, rather a free-form presentation kind of a stream that is divided into parts. Either way, I'll see how it goes.

Being a sheriff

I want to share my advice on being a sheriff. Holding meetings, planning, keeping track of things, communicating. There's a lot to it. You can do a bare minimum, which I will describe how to. Or, you could do all these other things extra, that I want to really share. Being a sheriff was my best experience of this class, so I really have things to tell.

Using projects

I was the one to enforce using projects this semester, and I think they should be used later on as well. They really stop working when nobody maintains them, but projects can really improve your experience. I want to show basic functionality, my own practices and uses for projects, such as: starting a new Project; using it to keep track of a milestone progress; compiling a list of priorities; sorting issues by different types... As the who used projects the most this semester, I think I will be the person to guide others on it.

Project keeper role

This will be somewhat of a video form for the document I made already. It will be a mix of personal experience, advice, demonstration of concrete things and explaining the structure of projects. Hopefully, it inspires someone else to continue on doing this role.

Students to come

Status of Telescope

We are now leaving Telescope behind in this current state. We need to be able to describe what exactly is "this state". What areas are there? What technologies are used? What is the progress on those areas? Where even is the code for this? How do you run it? Where did we leave things off? Basically, all you need to know about Telescope in its current state as a developer that wants to contribute.

Issues seller

This is a special category that I might continue as a series. The idea is to compile issues by a specific type, and present them in an appealing and intriguing manner. So that people actually get excited and want to work on them.

What types would be there?

• Compilation of "good first issue"'s, specifically for hacktoberfest;
• Issues that can be figured out and handled by a new open source developer. Also for hacktoberfest, but not the very simple ones. Just to show things I for sure know a student can do, which really brings confidence;
• Important issues to focus on. As in, what is a priority for Telescope? What is that single bug that ruins the whole thing every time?;
• Entry points to new technologies. If you are curious about docker, but you have never dealt with it before, what would be a good issue to start with?
• Completely new directions. Things that have not been researched and attempted yet. For example, the Slack bot issue. Or the email notification issue. It's interesting, it's unexplored and it will be completely owned by you!

Experience of previous developers

I am planning to not only compile information from current developers on the current state of Telescope. I also want to record and transmit their advice, their wishes, their views on what Telescope could be, what is lacking, what they want to see completed in the future.

Those are the ideas I have had so far.
I want to have meetings after this is technically officially over, but open source is never over. I've grown attached to Telescope, I want it to do well. My videos will hopefully help others.

Future blog posts?

I have enjoyed blogging, honestly. I might continue doing it, maybe about Telescope, maybe not. After all, it doesn't have to be about Telescope, or open source, or even coding at all. Not many will see it. But maybe that is why I want to write things sometimes. So that only some people get to lay their eyes on it.

GG WP