Surprisingly, there was a “Week 4” of the Community Bonding period. This might come as a bit of a surprise because there’s an assumption that the Community bonding lasts for 3 weeks, but it actually lasted for about 25 days. I’m unsure if it had always been this way, but this was how I met it. Week 4 had only about 2 working days, and there wasn’t so much done in that timeframe that I couldn’t squeeze into week 3’s blog post.
Weekly Check-in
Saptak couldn’t make it to the meeting, so Storm and I started on a lighter note. We had already done some good groundwork and shared our experiences on how it had been for us so far. Storm showed me a demo he was working on for an upcoming talk he was to have in the Netherlands’ Wagtail Space. We checked with our project tracking board to check what tasks could be marked as completed and hopped right into the more technical discourse.
Wagtail taught me a lot about the importance of testing, and to always think about test cases for any new logic I plan on introducing. We rubbed minds and made a list of things to check for, and I reflected the list in our Slack channel so we could add or remove from the list accordingly as time progressed. We also explored how to test some of the more complex functionality we had modified while creating the Proof of Concept. We agreed to involve more experienced members of the Wagtail team when the time came.
Before the meeting, I had shown my mentors a snippet of the second major piece of logic we would be incorporating for the project as a whole, and Storm had some concerns about how it might alter the existing user flow. It was a minor change, but editors who were used to something different would probably need a disclaimer on the new process involved. We agreed to test extensively for different scenarios and report findings the following week. This also meant that with the uncertainty in mind, the RFC would have to be tweaked even further. I’ll explain more about the technical details in the “Challenges” section of this blog post.
The meeting ended with Storm realizing I wasn’t on the Accessibility sub-team’s recurrent meeting invite list, and he updated that to include me. I also got invited to yet another core-team meeting
Core Team Meeting
The Wagtail core team comprises people across widely different time zones, so to balance things, they have a shifting schedule for their meetings. Essentially, meetings alternate between mornings and evenings weekly for all team members, so everyone gets to be in another person’s shoes concerning timing. This surprised me because I got the meeting notification a few minutes before the time (while I fully expected it to be in the evening). I joined early enough and the meeting started some minutes later. It was a brief one, and I re-introduced myself and mentioned the progress I had made with the RFC and when they should expect to receive a Pull Request for it. I also watched them try to interpret the new numbers they’d received in codebase contributions. It was fascinating to watch, and I got a sense of why tracking all the metrics in a GitHub organization was essential to the survival of any Open Source Software project.
It was a brief meeting so when the key things were touched on, the meeting was dismissed, and I continued with my day.
Accessibility Sub-Team Meeting
This meeting was a story for the books. My lead mentor (Storm) chaired the meeting, and with him coordinating it, my confidence had an even bigger boost. We talked through the progress so far, and we elected to show them the RFC document draft. It was still a Google Doc so it was easy to send a link, but he shared his screen and walked the team through it while he told me to set up a feature demo for the team. I wasn’t expecting to do a demo so my tweaks from the night before were still very much unrefined. I did a quick rollback and proceeded to set things up. In a few minutes, I got everything running and was waiting to share my screen and present the new features to the team.
He finished his walkthrough of the document and I proceeded to show the team and explained how things worked. It was going quite smoothly until he asked if I could show them what a “Live” site would look like with it. He helped me with a quick setting to make, but as soon as I clicked “View Live”, the admin site crashed. My heart sank to my stomach, but he just said in the most convenient way “Oh, you must have forgotten to add the template file”. Yes, I did. Amidst the rush to set things up, I forgot the template file because it wasn’t important up until it was time to view a live site.
The team did agree that the crash was a simple one and the proof of concept was already shown. The meeting ended on a good note, and although I felt a bit sad about the demo crash, both my mentors assured me that it was a good presentation regardless and that it was really nothing to worry about. Definitely a story for the books.
What I learned
In week 4, I decided to stop using the Docker setup as it was needlessly intensive on computer resources, and I could have gotten much faster speeds on a purely native setup. The reason I had used it for so long was because Wagtail mentioned in their documentation that installation support for Windows was a work in progress. However, I was daring yet patient enough and decided it was finally time to give it a shot. It took me about half a day, but I got things to work, and my developer experience got significantly better. I no longer had to wait for 6-8 seconds for change reloads. I could run things in my own terminal without having to use Docker’s annoying terminal. I could also use less battery power (in the absence of electricity), and there was less computer fan noise. It gave me a chance to play around with even more ideas because it took the inertia away.
Remember I already had a previous setup with docker with my changes and branches? I cloned the Git repo from GitHub again and fixed all necessary remotes. I set up my virtual environment so I could run multiple projects using my experimental version of Wagtail on my local machine, and read much better about Python’s package management systems. Essentially, the week not only made my developer experience with Wagtail better, but also strengthened my understanding of Python basics.
Finally, to cap off the week, after the accessibility meeting, Storm organized a virtual meeting to help me understand some things better. He took his time to thoroughly explain Wagtail’s Block management system with an SQL browser. He did such a thorough job of helping me see things more clearly. I really did win the GSoC mentor lottery.
Challenges
All the learning did come with some challenges. From my RFC review process that was starting to tell on me, to my local setup not seeming to work, to my demo crash, to even getting the proof of concept working, it was a week that kept me mostly on my toes.
There was also a challenge with the image_description attribute we proposed. The initial plan was to make it mandatory, but the existing flow of the image uploads was one where a user could upload an image and exit the screen with the certainty that it would be uploaded. However, while making the field mandatory, the configuration would have to be such that images would not be uploaded until the attribute had been filled. Users who are used to the former flow might absent-mindedly navigate away from the page out of habit (without filling the attribute field) and it would lead to inconsistent UI behavior from what they were used to. We decided we would explore some more options for week 5.
This was my week 4, and it was a personal thriller.
Cheers. 🥂
