Creating Open-Source Resources for The Community (Ep 2)

Mastori: The building Journey. A personal Recollection

Creating Open-Source Resources for The Community (Ep 2)

Mastori, as the name implies, is a platform where community members can share their blogs and articles. The name "Mastori" originates from Kenyan slang, sheng, meaning "many stories." Our vision is to provide a space for individuals to write about topics that have a positive impact on the growth of other developers. Additionally, the platform serves as a resource pool for those seeking specific tech solutions to their problems.

Personally, I've always been a passionate storyteller who values intricate details, which is why this project resonates with me. I envision a community-built platform where I can share my tech stories.

Our journey began by receiving user stories and understanding the goals of each team. Within the user stories, we encountered scenarios where developers wanted to write articles accessible to the public. Inspired by these stories, our design team created a mock-up of how the blog might look.

During our initial stand-up meetings, the team's vision started to take shape. We began by modeling the application and documenting the requirements for the minimum viable product (MVP). Every Thursday, under the guidance of Hudson, a backend developer from Kenya currently working in Germany and the CTO at SpaceYaTech, we held meetings to discuss the development of Mastori. Each meeting proved to be a progressive and collaborative space, allowing every team member to contribute their ideas.

These meetings proved to be highly informative, especially since many team members were new to specific technologies. I remember a particular instance when we were modeling the application and someone suggested using Universally Unique Identifiers (UUIDs) instead of conventional serial IDs. This idea sparked subsequent research, making the meeting's information invaluable to the entire team.

At this stage, all teams designers, backend developers, frontend developers, and project managers came together to model the application as a cross-functional unit. It was an exhilarating experience, and I was always eager to see how we would execute the task.

Once the modeling phase was completed, we divided into our respective stacks and began the actual building process. We set up the GitHub repository, and with the very first commit, we marked the beginning of development. However, things didn't progress as smoothly as expected.

The initial step was to set up the application, which seemed straightforward at first. However, since Mastori was a community project aimed at encouraging contributions, we faced a challenge. The next commit came from a fellow contributor named Sang, who had created the entire blog application and pushed the code. While this was impressive, it meant that we hadn't contributed anything yet, posing a problem for beginners and those unfamiliar with collaborative development. In response, I reverted the commit and we created new issues to foster inclusivity and involve even those using Git for the first time.

From these review meetings, Django Labs was born. They transformed from mere review sessions into articulate explainers, delving into the various technologies employed in building Django applications.

This process became something we all grew to love as we continuously refined our work, ensuring inclusivity and having a consistent and logical connection between ideas, arguments, or statements. We've been on the Mastori journey for a while now, and every time I open the local dockerized API version on my laptop, I feel a surge of adrenaline. I'm eager to see more people being able to consume the API and experience the complete application that we will finally ship.