Everybody Struggles
It’s been two weeks since I started my internship at Outreachy. In my first week, I was to install all the tools I would need for the project and sign up for administrative accounts. Some of the tools included GitLab, Toolforge, and Python, while the accounts I needed to sign up for included a Wikimedia Developer account, creating a research page, and deploying a simple “Hello World” tool using Flask and FastAPI. And in my second week, I was to design a foundational backend for the project. This involved accepting a list of article titles, calling the LiftWing Quality API for each one, parsing and structuring the response to extract the overall score and key feature scores (references, images, etc.), and returning a simple JSON output for the frontend.
I faced many ups and downs and lessons along the way. Let me take you through it all!😊
Week 1 - Installation, Sign Ups, and my Struggles.
I am happy to announce that I wasn’t expecting to struggle with the installation process for more than half of these tasks, but I did—haha. The first task I worked on was signing up for my Wikimedia Developer account, and I faced no issues doing this.
The struggle started when I tried to create a GitLab account. I received a pop-up message stating that, to avoid spam, I needed to have a trusted contributor status on Phabricator. A bit of backstory on what Phabricator does: Phabricator is one of Wikimedia’s communication channels.
I began by asking my mentors for help in assigning me a trusted contributor status, and after that, I was able to create a GitLab account. Hurray!
The next task I faced was setting up a research page for the project, where I was to describe the goals, functions, timeline, and deliverables of the project. My mentor was kind enough to assist me with examples to see how it is done. So, I followed the template and wrote about my project here.
While doing this, I realized that I needed to create my personal page on MediaWiki so users could see who is working on the project and learn a little about me, so I published it here.
When setting up my personal page, I struggled with adding my profile picture, but by reviewing a similar example page’s raw code, I was able to do this seamlessly. So, if you are looking into editing a Wikimedia page, looking into the code of a similar example to understand the syntax would be very helpful for you. These were also my first edits to a page on the Wikimedia Foundation. I was so excited to learn something new.
The next task I did was to set up my Toolforge account. There was a simple tutorial on how to do this on the main official website here. I followed the tutorial and was able to get an SSH code from my laptop and request access to be able to create my tool for the project, the microtask generator. I described what my tool would be doing and how it would benefit the Wikimedia community, and my request was approved within two days.
When it was approved, I began setting up Toolforge on my local computer. I was to deploy a simple “Hello World” tool and followed a tutorial shared by my mentors I struggled with logging into Toolforge on my local computer because I was following an old tutorial where the method I was using was no longer working. But after my mentor shared the updated documentation, I deployed my tool in less than 10 minutes.
This is why it is good to always read the latest documentation when starting your work. Don’t just jump into anything, and you will save yourself valuable time. Also, learn to ask questions when you are stuck, because it was me doing this that brought help from my mentors, which I am grateful for. Open source is about asking questions and answering questions, no matter how small, as it gives birth to a learning and growth process for both the asker and the answerer. I am thankful for it.
As someone who struggles with asking small questions, thinking they are irrelevant, this was one valuable lesson I learned in my first week of Outreachy, and I would encourage you to keep asking those seemingly small questions, as that is where the most understanding comes through. Asking questions also opens the door to more solutions.
When I asked my mentors for help, I got a suggestion to use a better API that has some improvements over Flask, which is FastAPI. I began working on this and used more recent documentation to install it on Toolforge, learning from my first mistake. Everything was seamless until I got to the final step. I interpreted the step wrongly by using the example’s GitLab address instead of my own and I almost ripped my hair out. It took careful review of my code to finally spot it. I laughed at myself and corrected it, and it worked immediately after doing that.
When I shared my experience with my mentor, he encouraged me by saying that getting someone to look at your code is always very helpful, and I agree. What I can’t spot quickly can often be spotted by a fellow developer who has gone through a similar situation. So many fun things to learn! Click here to view!
After deploying my FastAPI tool, I was done for the first week and ready to continue my tasks for the following week.
Week 2 - Setting up the Backend
Week two came, and I began by having a meeting with my mentors, where I asked questions about the expected deliverables and also confirmed whether my approach was right. The first thing before starting any project is to think about how it is going to be connected. I read about the LiftWing API to see what it requires, and I learned that I would need to use the latest revision ID for a Wikipedia article as well as the Wikipedia article titles themselves.
The latest revision ID refers to the most recently updated version of a Wikipedia article. As you may know, Wikipedia articles and documentation are written by the public and can be edited by the public. So, retrieving the latest version is important to ensure we are not returning a quality score for content that has already been corrected.
The first thing I did in VS Code was to write a Python function that could retrieve the latest revision IDs from Wikimedia’s popular API, the MediaWiki API. I read the documentation for this API to understand which properties were needed to retrieve the revision IDs and included them. Then, I used the revision ID and article titles as parameters to call the LiftWing API in another function. After that, I set up an endpoint and wrote the code to make everything work together.
However, the first error I encountered was an internal server error (500). I reported this to my mentors and was encouraged to set up a branch on GitLab to share the code. My mentor reviewed the code and gave me suggestions on how I could correct and improve it. Once I applied the changes, my code was up and running immediately.
I was so excited and thankful. Collaboration and teamwork are truly very important in programming. We have so much to learn from each other, and I am grateful to experience it.
Woohoo! This was the end of my week 2 tasks. Everything was completed, and I’m ready to begin my tasks for week 3. Stay tuned for more updates, as I will be sharing my further experiences as I work on the front-end and further modifications of the backend of my project in the coming weeks!
Thank you for reading! :)
