I would like to write about my current experience in Telescope, and since we are nearing a 3.0 release, I would also like to talk about the area that I have, without a doubt, focused more on the entire term: the dependency-discovery service.
Depedency-discovery
The area that I have worked on the most is the dependency-discovery service, and thus, it is my duty to see it being used by the 3.0 release. Although I have worked on some of these issues through this week, I would like to write about this as if I haven't (because this blog was supposed to be posted a week ago...).
So, if this was the week of March 20th, what I should focus on to guarantee the shipping of the dependency-discovery service?
- Finish the collection of issues from GitHub repositories that are associated to the packages.
- Design the first front-end for the service.
- Add tests for the service.
I am oversimplifying the points above, as I don't want to delve deeply into implementation details.
An important point that I have to discuss is what risks I will be facing that could prevent me from shipping the dependency-discovery.
A major risk I need to worry about is that nobody would be able to review and approve my code. Now, since my PRs tend to be small (less than 300 loc changes), I think this is unlikely. Either way, I need to keep my PRs small so that anybody could review (even if they are new to the service).
Another risk is the front-end. We are nearing the 3.0 release, yet there are no signs of a front-end. I am not really sure how it is going to turn out, but I might want a really simple design that does what it needs to do, which is: facilitate finding issues of several repositories that are dependencies of Telescope.
I will do my best to bring this issue to fruition and see other students using it.
Top comments (0)