Google Summer of Code 2018 with Debian - Week 3

Coming to the third week of GSoC felt like it was part of the daily schedule since ever. Daily updates to mentors, reviews, and evaluations on merge/pull requests and constant learning process kept my schedule full of adrenalin. Here's what I worked on!

How A Project Is Made with Sanyam Khurana

Building an idea into a project seems like a lot of work and excitement right? You can do all sorts of crazy stuff with your code to make it as amazing as possible. Use all sorts of cool-tool in hope of making something out of it at the end. But this is where the problem lies. Diving into the sea of amusement and uncertainty never promises a good ending. And hence, my mentor Sanyam Khurana and I sat down for my intervention in hope of structuring the tasks for good. And this is how a project begins. Sanyam with his experience in Open Source as well as industry taught me the importance of dividing tasks which should be atomic and should clearly define what we are trying to achieve in Plain-English. For example, when you are trying to make a blogging website, you don't create a pull request with all of the functionalities needed for the blog. First, think about the atomic tasks which can be done independently. Now create a series of these tasks (we call them tickets/issues/features). So, you have a ticket for, say, setting up pelican blog. Another for creating a theme for your blog. Another for adding analytics to your blog and so on.

Now, you can also create boards or table with columns which define the state of which these tasks lies. A task may be in development or in testing or review phase. This makes it easier to vizualise what needs to be done, what has been done already and what tasks should be in focus currently. This methodology in a broader sense and proper framework with a lot of disciplines in action is known as Agile Software Development.

Dividing Project into Tasks

After learning much about how to proceed, I sketched out the way in which I can separate out the atomic features needed for the project. We're using Debian hosted Redmine for our project management and I started jotting down the issues, to begin with. Here are the issues which shape the beginning of the project.

• Create Design Guideline - The first issue in order to create a reference GUI design guideline for the application.
• Design GUI for Sign Up - Design mockup following the guideline to describe how Sign Up module should look like on the GUI.
• Design GUI for Sign In - Design mockup following the guideline to describe how Sign In module should look like on the GUI.
• Create Git repository for the project - Project mentor Daniel created this issue as the first step which marks the beginning of the project.
• Initializing skeleton KIVY application - After a dedicated repository has been created for our project, a KIVY application has to be setup which should also include tests, documentation, and changelog.
• Create SignUp Feature - After the skeleton is setup, sign up modules can be implemented which should present a GUI to the user in order to create the account to access the application. This screen should be the first interaction with the user after they run the application for the first time.
• Create SignIn Feature - If the user is already signed up for an account on the application, this screen will be the medium with which they can Sign In with the credentials.
• Add a license to Project Repository - Being an open source project, picking up license is a very elaborative process where we have to also look at all the dependencies our application has and other parameters. Hence, this issues is more of a discussion which will conclude by adding a License file in the project repository.

These were some of the key issues which came up after my discussion with Sanyam (except creating git repo which Daniel kickstarted). These issues were enough to begin with and as we progress we can create more issues on Redmine. As part of the first couple of weeks of GSoC, I've already completed the first 3 design issues, I also wrote a blog explaining about my process and the outcome. So, for the third week, I started with initializing skeleton KIVY application.

The First Merge Request

Don't be confused if you are a Github native, since we are using Debian hosted Gitlab (called salsa), it has Merge Request in place of Pull Request.

The issue which I was trying to solve in my first Merge Request was Initializing skeleton KIVY application. It was just to create a boilerplate from scratch so that development from now on would be smooth. I set out to achieve following things in my Merge Request

• Add a KIVY application which can create a sample window with sample text on it to showcase that KIVY is working just fine
• Create the project structure to fit documentation, ui, tests and modules
• Add pipenv support for virtual environment and dependency management
• Integrate pylint to test Python code for PEP8 compliance
• Integrate pytest and write tests for unit and integration testing
• Adding Gitlab CI support
• Add a README.md file and write general description about the project and all it's components
• Add documentation for end user to help them easily run and explain all the features of the application
• Add documentation for developers to help them build the application from source
• Add documentation for contributors to share some of the best practices while contributing to this application

Here's the Merge Request which resulted in all of the above additions to the project. It was a lot of pain getting CI to work for the first time, but once you get a green tick, you know what ticks CI to work correctly. Throughout my development process Sanyam helped me with reviews and it finally got merged into the repository by Daniel.

Conclusion

This week kickstarted the main development process for New Contributor Wizard and gave me a chance to learn about project/software management. I will be creating more issues and share about what I'm working in the next week's GSoC blog.

Please share the blog if you like it