What I did: a lot of structure

I have mostly been discussing, learning, formatting and structuring things this week. Perhaps I don't produce that much code, but I definitely do some work.

The sidebar

Look at this mess.

This is the sidebar now.

I didn't know at first, if it was even something I could fix.
Issue

This took me some reasearch on how wiki pages work, I have found an app that would generate pages for you, however I decided to have a full control over them and make a custom sidebar. It was one of those things that annoyed me every time I'd look at it. Not anymore!

Projects

This is the largest one. I started with a discussion.

• I first went over the old overview file and revisited the sections described. Now at least I have (maybe an outdated, but) structure. I need to check each one to see for myself what it does. As I discover them, I should leave behind a doc that would summarize what I learned. In the end I should have a complete picture with all the components linked and clear.

• I then looked at the Projects that existed. You don't see much in here now, because I removed most of them. Having to look at how they were used, I saw a flaw in the structure. That made me reconsider what should a Project even be.

• With Jerry's help, I could outline a concept of a Project. As I figured that out, I began removing the old Projects, as they no longer would fit within that definition. I still struggle to figure out if I should make a project for an idea, or it should be left as an issue. Hopefully, as I discover more areas that part will become clearer to me.

• I was curious to see what a Project Beta is. After getting permission to play around, I figured out it has all the functionality of old projects, but along with new extra features. That left no reason to not switch for beta, since we are redoing the projects and we are not losing anything by switching towards the new realm.

• I assigned some ideas as Projects that were already discussed as such. I have yet to find many more Projects to add and organize.

• Project structure. This was something I found lacking in the previous approach. There should be a single page that would describe the project and have links to all the resources you will need to get involved. That page has to he the top left page in the project and has to always include specific data. I came up with a single structure, that works like a lifecycle. First, a project is an idea that is a discussion. Then it becomes an adult and is an issue that keeps track of other smaller parts of the project and has all the documentation needed later. I call that a parent issue. In the end, as the Project gets completed, it retires and the page becomes a part of documentation. Since during its life it was collecting all the useful data, we don't need to gather much information when it retires, we just need to format it well.

Issue templates

In a discussion, Jerry suggested something I didn't think to include before, but realized we actually need. He later made an issue that I completed. I ended up making two templates, one for a new project, another for a documentation task. Aaaaaaaaaand that broke master.

How I broke master.

This week was my time to break master... I had my turn. I did it with.... you wouldn't believe it.. .md files! Look, I had to fix it too. Basically what happened is that I added the files through GitHub, without linting or making a PR. Prettier checks did not like my .md files. There was a short panic on slack, thankfully I didn't go to sleep yet (magically). Yes, you could say I did a PR this week technically. Maybe if I didn't mention I caused it in the first place, it might even look good.

Mobile PR

There was this old issue and a PR we got assigned as the new Front end team! As we found out, the solution I came up with wasn't as easy to implement, so I decided we complete the easier part and make another issue for the more difficult part. The PR is now there, so we should be done with the task.

What I also found out is that I don't actually want to be in the front end team, since it's mostly React...

Architecture overview

As I am discovering Telescope's components, following the old doc I will be adding that information into an overview of my own. It is work in progress, but I will make it clean and informational. Something like this so far:

Project keeper

It is clear that projects will not be maintained unless someone maintains them. I decided to make up a specific role for the students to come, so that there is more chances to have it filled. I have drafted a page about it. I will work on adding information to it as I come back to re-evaluate. It should be a solid doc towards the end of semester so that someone could pick up the role after me.

Themed releases

This is an idea I had which is more about how we work on releases as students, rather than Telescope itself. To keep it short, each week will have a theme that would push people to prioritize it, rather than having each release be equal and same.

Actual docs

I have been assigned to make many docs for many new concepts. My task for the weeks to come will be to bug people to explain me how to use their things, what those are and where they are located. Then just make a doc about it. Cool.

Docs service?

Since now there are many docs to be made, this idea was born, to give those docs a better place to live. On Telescope. It wouldn't have to change much, since MDX is something that uses .md files. So the old files we have already will work. I like what this project solves, I like how it will improve developer experience of generations to come.

Twitch in Telescope!

I was assigned this as the one streamer that dared to announce I am one during the meeting. It is a reasearch task about a topic I am somewhat familiar with. However, I'm not that sure how I will deal with the whole... react... part of Telescope. At the very least I could find out what steps need to happen for someone to make it work.

A lot, but a little

It was a weird week. I felt like I didn't do enough, but at the same time I did a lot of small things all around the project. I definitely didn't do enough code and barely know how to do PRs. I will fix that tomorrow, as I'll get in a call for someone to explain me the process. I will need to know those things, like reviewing and testing someone's PRs next week.

Oh, right, did I mention? I'm the next Sheriff. I am both excited and terrified. My performance in meetings will depend on how I will feel that day, which doesn't sound reliable at all. However, it has a potential of being awesome as well. We'll see!