My Release 0.4 Open-Source Journey - From Planning to Delivery

Introduction

At the start of this journey, I knew I wanted my last project of opensource to be something meaningful, educational, and technically rich. The plan was to contribute to an open-source project—in my case, the Academic-Learning-Centre-Admin-Scripts—by adding new features, documenting the process thoroughly, and engaging with the community. The goal was not simply to open a PR and be done, but to do the work in the open, interact on GitHub, refine my changes based on feedback, and ultimately have my contributions accepted and merged.

This was my first real engagement with a Python-based codebase beyond a basic course I took a year ago. Plus, I’m currently juggling five other courses and navigating internship interviews, which made time management a significant challenge. I needed to set realistic goals, approach them systematically, and track my progress over several weeks.

Setting the Stage (Week 1 Plans)

In the first phase, I planned out what I wanted to accomplish:

1. Why Choose This Project?
   
   The Academic-Learning-Centre-Admin-Scripts caught my interest because it automates tedious timesheet generation from tutor appointment data. This felt like a genuinely useful automation that could be extended and improved. I chose it because:

   • It involves Python scripting and automation (areas I need more real-world practice in).
   • It’s already somewhat functional, but clearly has room for enhancements (like automated emailing, documentation improvements, and better deployment instructions).
   • Contributing here would let me leave behind a helpful tool.

2. What Did I Plan to Do?
   
   I decided on a set of tasks:

   • Improve and modularize email functionality: first generate email data, then send emails automatically each week.
   • Enhance the existing documentation by adding a detailed user guide for deployment.
   • Eventually refine coding style and structure (PEP 8 compliance, better variable names, etc.).
   • Write blog posts and actively use GitHub issues, PRs, and discussions to collaborate in the open.

3. Approach and Goals:

   • Allocate a few hours each week specifically to coding and community interaction.
   • Keep an eye on the calendar to ensure I finish the core contributions on time.
   • Communicate openly: ask questions on GitHub issues, explain what I’m doing in PR descriptions, and write weekly blog posts to reflect on progress.

By the end of this initial planning phase, I felt confident but cautious—I remembered that I had those five other courses and ongoing internship interviews. Time management was crucial. The plan was to incrementally build my solution and share each step publicly, ensuring I wouldn’t overcommit and lose track.

Mid-Project Progress (Week 2 Update)

After about a week, it was time to assess what I had done and where I stood:

1. What I Managed to Complete:

   • I integrated an emailDataGenerator function and tested it. This function returned structured email data, including the weekly date range and a friendly closing.
   • I implemented a sendEmail function capable of dispatching the updated timesheet as an attachment to the admin office. This involved diving into SMTP details, handling attachments, and testing the workflow end-to-end.

2. Sticking Points:

   • Handling credentials securely and deciding on which day to send the email was trickier than expected. I learned about environment variables for storing email passwords and considered using cron jobs for scheduling.
   • Balancing this work with my other obligations was tough. I found myself working late at night to implement and test features. However, explaining my work in blog posts and PR descriptions helped clarify my thoughts and keep me motivated.

3. Adjusting the Plan:
   With less time than anticipated, I decided to focus on making sure the main features (weekly emailing, user guide) were solid rather than rushing to do everything at once. I communicated any trade-offs on the GitHub issue trackers and in my mid-week blog updates. This open communication might have helped if anyone had feedback or suggestions.

By this midpoint, I had a working solution that fetched data, updated timesheets, and could now email them automatically (on a chosen weekday, like Monday). I also committed to writing a USER_GUIDE.md explaining how to deploy and run the script in different environments. The knowledge that I was improving an actual tool was gratifying, even though my schedule was tight.

Final Results (Consolidated Outcomes)

Now that the work is completed:

1. Achievements:

   • Successfully integrated the weekly emailing feature. The script not only generates a timesheet but also attaches and emails it on schedule.
   • Wrote a comprehensive user guide (USER_GUIDE.md) detailing setup, configuration, scheduling, and secure credential handling.
   • Refactored the code to be cleaner, more modular, and easier to maintain. This included adopting a clearer coding style and reorganizing logic into functions and separate files (email_generator.py, email_sender.py).
   • Followed through on the open-source etiquette: made branches, opened PRs, wrote detailed commit messages, and documented the process in blog posts and PR descriptions.

2. Measuring Success:

   • The PRs were successfully created, well-described, and reviewed.
   • I learned how to handle date ranges, manipulate Excel files using openpyxl, parse HTML with BeautifulSoup, and integrate SMTP emailing.
   • My confidence in Python went from “rusty and unsure” to “capable and resourceful.” I can now handle not only the coding but also explain it clearly to others.

3. Lessons Learned:

   • Technical Growth: Improving code architecture and adding new features taught me how to read documentation and implement library functions effectively.
   • Open-Source Process: Working in the open, writing technical blog posts, and creating PRs helped me understand the importance of communication and transparency.
   • Time Management & Priorities: Despite five other courses and ongoing internship interviews, breaking the project down into smaller tasks and writing weekly blog updates helped maintain steady progress. Setting realistic goals and adjusting them mid-course was critical.

4. Community Interaction:

   • Although I had limited direct feedback from maintainers, writing PR descriptions, linking issues, and documenting changes thoroughly meant that if maintainers or other contributors arrived, they could understand my changes quickly.
   • If there were community Slack channels, Discord groups, or GitHub Discussions, I would have participated there as well. The instructions highlighted that being active in community channels and discussions is part of the open-source ethos. Even if minimal feedback came back, the openness and clarity of my workflow prepared me for future collaboration.

Conclusion

What started as a plan to improve a Python script and document my journey ended in a successful completion of all core objectives. I created blog posts (rolled into this single long-form summary), contributed meaningful features, wrote comprehensive documentation, and maintained a professional Git workflow. The experience gave me confidence in my technical and communication skills.

If anyone else stumbles upon this project looking for guidance on automating timesheets or sending weekly reports via email, I hope my contributions and documentation will help them. Despite my heavy workload—juggling five courses and preparing for internship interviews—I’ve shown that with careful planning, incremental progress, and open communication, one can make a substantial and high-quality contribution to an open-source project.

This final retrospective closes out my 0.4 journey, capturing the entire arc: from initial planning and goal-setting, through mid-project adaptation and problem-solving, to delivering a polished, documented solution ready to be merged and used.