Introduction
This blog post would be excellent reading for people who:
• Currently wants to begin discovering Software Development
• Looking for further experience in Software Development carrier
Desires to know,
• How substantial open source projects work.
• How 'it's made' inside the Telescope project.
• How to boost yourself to new pieces of knowledge
Quick intro about Telescope.
Telescope is an open-source web server and client application for aggregating and presenting a timeline of Seneca's open-source blogs with more than hundred forty-five contributors.
To say shortly, that's a blogs aggregator tool.
Our plan is:
• Issues: How does a team of twenty people maintain hundred of issues?
• Pull Requests: How do we handle new pull requests?
• Enhancements: New React Native application?
• My research work for CloudFare and better caching?
• Being a 'Sheriff' at Telescope?
Issues: How small team of twenty people maintain thousands of issues?
Currently, Telescope has one hundred thirteen open issues, and one thousand one hundred sixty-eight closed, making it hard to control. We are trying to separate our work areas by custom labels and creating different teams. Every week we have two scheduled meetings and sometimes from two to five spontaneous meetings to handle various bugs or questions we face.
We almost always talk about open issues with the team at scheduled meetings and assign people for new issues. For our team, that's a great way to handle the situation and not make problems overwhelming.
Pull Requests: How we handle new pull requests?
Currently, we have from fifteen to twenty-five pull requests on hold every day.
Every two weeks or so, we push new releases into production that contain a lot of updates by pull requests(PR). Primarily for each created PR, we have one or two related issues that can be closed. We need at least two maintainers to agree with the new changes for PR to be accepted. We try to keep PR as small as possible, and we always ask for smaller commits to be ready to handle errors/bugs if it happens.
Enhancements: New React Native application?
How do we handle new ideas or enhancements in our
Telescope project?
First of all, let's take a quick look at our current stack and functionality. Telescope by itself
consist of monolithic backend(Node.js), micro-services(Authorization control, blog post parser, e.t.c) and front-end(React).
We had an idea long ago that mobile would be excellent for our project, but only this week decided to start the first steps in implementing. In a big project, it is much harder to implement something because it can reflect on many parts of the project. Just for instance, here are a few issues to handle:
What stack will we use for our mobile application?
What will be great for our situation?
Who will organize the process and group?
Who had previous experience and so on ...
We are always open for new contributors if you want to help us look here.
My research work for CloudFare and better caching?
Now, let's talk about my personal experience that is happening currently in my work here
Cloudflare is a global network designed to make everything you connect to the Internet secure, private, fast, and reliable.
We currently use Redis to cache most of our static information on our front-end, but we still have a few static files we need to cache, and CloudFare seems like a great tool.
Also, we hope to implement serverless functionality in future. Research work is a much more challenging task than it felt at first because you need to analyze tons of information, combine it into something meaningful, and only after offer to add. After a few meetings, maybe it will be a chance to implement something small and check how it will work.
Being a 'Sheriff' at Telescope?
What is Sheriff? I don't know who created this idea, but it's the best use in massive projects.
Sheriffs help steward and manage the project's infrastructure and make sure that the team can function optimally at all times. Their primary role is to help developers shepherd their code through the review process to be landed cleanly and do so without breaking any tests, CI automation, or infrastructure.
At any given time, two Sheriffs are on-call, with a third on the backup as needed. We always maintain at least two to get changes and reviews done quickly if necessary.
Conclusion
That was a great week of diving deep into the project's architecture.
Another great story for Software Optimization with assembly/machine language.
It is easy to work with the current stack, so if you are interested in contribution, here.
Have a great coding!
I will add something else here. Maybe not.
⚠️ Repo for future first work: here
Links
🖇 git https://github.com/aserputov
🖇 Twitter https://twitter.com/aserputov\
Post #3 Part 1
Top comments (0)