Toward Telescope 3.0

Last year at this time I was writing about what we hoped to ship in Telescope 2.0 as part of OSD700/DPS911. We had 10 students plus a fairly active set of community members outside of the class. A little over 3 months later, we shipped Telescope 2.0. It included fixes and features done in 400+ pull requests, and the project sat at ~20K lines of code.

Technical Debt from Telescope 2.0

Today in January of 2022, I'm writing a similar post about Telescope 3.0. This term we have double the number of developers (it will be a good chance to test Brooks' Law) and a fairly stable and mature code base. The Telescope 2.0 work improved a tremendous number of areas in the project, but we didn't manage to get everything finished. I wrote a bit about that work in this discussion post. I'd summarize the outstanding bits of work this way:

Complete the microservices migration and delete the src/backend code.
Improve and optimize our docker containers' build and deployment workflows
Complete the Users and Auth services, and finish the sign-up, sign-in flows
Improve and extend our Search back-end and features
Improve and expand our Dashboards to help visualize and analyze the project more easily
Figure out a better back-end database story to supplement our use of Redis (cache) and Elasticsearch (search).
Improve the on-boarding, setup, and developer experience of the code. Make it easier to get started working on Telescope, since all of our devs are students who don't know the code.
Maintain our existing code. We still have lots of bugs!

New Areas of Focus

There's also some interesting, new work that I'd like to see us explore in the 3.0 timeframe:

Start work on a new React Native mobile app to accompany our existing web app. A lot of students in the course want to work with React, and others are interested in mobile. Combining the two seems like a great way to include as many people as possible. Also, nothing shakes-out bugs in a back-end API like implementing a second front-end client.
Continue to prepare the back-end for an eventual cloud migration. I'm not sure when we'll be able to move to a pure cloud deployment, this term or in the future (it depends on money, to be honest). But I'd like to get the code in shape so that when we're ready to pull the trigger, everything is ready.
Integrate GitHub data into the app for better discoverability of upstream contribution opportunities and visibility of what students are working on. Telescope keeps track of student blogs, but a lot of what they blog about is work on GitHub. Since GitHub has such a rich, open API, we should be integrating it into our back-end so that we can index and search it. I also want to see our Telescope dependencies become more visible in the dashboard so that students can find ways to contribute upstream. In 2022 it's becoming clear that open source requires the community to pitch in and help maintain the code it uses. You can use and never contribute back to open source, and lots of people do. But I think that teaching the students how to become active members of the ecosystems they work with is critical to the sustainability and long term success of open source. If we're going to help maintain our dependencies and tools, we first need to know what they are. Right now we don't have any good way to discover opportunities to get involved in upstream projects. I'd like to see Telescope help to solve that. Next September, when I run the first open source course again, I'd love for the students to use Telescope in order to find the Issues to work on for their projects.

Our Priorities

I asked the current team to blog about their own individual priorities, and I've tried to capture them in the wiki. I'd summarize the areas that I saw people write about this way:

React, TS, next.js, web front-end
React Native front-end
Back-end API work and Microservices
Project Tooling and Automation
Docker, containers, cloud migration
Developer On-boarding, Documentation, Developer Experience (DX)
Dashboards, Data Visualization, GitHub Data Integration

We have seven milestone releases to explore these areas, research, develop, and ship code. Our next task is to break up the work into pieces, start filing issues, and get it assigned. I'm going to push the team to take ownership of this work early, and get them all involved in planning and decision making. It's easy to feel like an outsider, and wait for "someone" to tell you what to do.

How We'll Get There

In our case we need to leverage the fact that there are so many people on the team. This can be a curse or a blessing, and it depends on how well we do at breaking things up into smaller pieces.

Everyone needs to pick an area or two to focus on, and start by taking ownership over it. I want to make sure that we have a culture that favours action over a wait-and-see approach.

I also want to encourage the students to think about working differently from their other courses. I'm not trying to stop cheating in this course. Instead, it's fine to get a few people on an MS Teams call and pair program together. When you get stuck, hop on Slack and talk about your problems with the team. As you work, blog about and share your code. Update your colleagues about your progress in Issues and Pull Requests. Above all, do your work in the open and don't vanish for a week so you can surprise everyone with something. "Surprise is the opposite of engagement," and open source communities are about engaging.

The questions we all need to answer this week are these:

what do I want to build, fix, and contribute as part of my goal(s) in Telescope 3.0? Be specific.
who are the people that can help me succeed (collaborators, testers, reviewers)? What do I need from them? Make sure you've introduced yourself and started those relationships. How will we work?
what's the minimal, realistic version of these goal(s) that we can ship in the Telescope 2.6 release? Shipping a complete feature sounds great, but it's not doable in a single step. Break the work down into bite-sized pieces of work that can be developed, reviewed, and shipped. How can you parallelize the work across the team so that we divide-and-conquer?
what do I need to research and implement in the next three weeks so that this happens? We all need to learn things in order to do the work, and baking in time to do background research is key.
which Issues do I need to file this week in order to make sure this work happens? If it's not filed, it's not being tracked. If it's not being tracked, it's not being scheduled. If it's not being scheduled, it's not shipping.
what are the risks for this work? How do I prevent failure?

We're going to repeat this process over and over again in the coming weeks and months. Our first time through it will be a bit harder, since everyone is getting up to speed on how the project works, meeting the rest of the team, and trying to set an initial set of goals. Once we've got people pointed in the right direction, I think it will get easier.

Get Involved

Wish us luck! If you'd like to get involved, you're welcome to join us at https://github.com/Seneca-CDOT/telescope, and we'll happily give you work to do, too!