Hey there! It has been about 15 days since I had written my last blog. It is time for the next one. In this blog, I will write about my experience in GSoC so far. I want to tell you about how I selected my project, how I prepared my project proposal, and what did I do after getting selected.

How did I select the organization?

So, let’s start from the beginning! I started considering to apply in GSoC in late February. I first came to know about GSoC just a few months back. My knowledge about GSoC and open-source was quite limited. One of the first things that I did was to go through the GSoC website and learn more about the program. Being a beginner in the open-source community and also coming from a non-CS background I had no idea which organizations take part in GSoC and which of them would be most suitable for me. At this time, the mentoring organizations for GSoC”22 were not announced. I decided to check out mentoring organizations from past programs to get an idea. I wanted to work on a project that involve Physics or Astrophysics, and to my surprise, several such organizations did take part in previous programs.

From this search, I got to know about OpenAstronomy. It is an umbrella organization of several open-source astronomy and astrophysics projects. From their GSoC webpage, I came to know that they are applying to participate in GSoC”22. The webpage also contained guidelines for contributors, a list of project ideas for this year and for past years, and information about how to get in touch with mentors and communities of various member organizations. All these were quite informative and useful. I also checked out several other organizations as well. All of them had such information available online in various forms. A few days later the participating organizations were announced by GSoC and OpenAstronomy was one of them. By this time, as directed in contributor guidelines of both GSoC and OpenAstronomy, I had introduced myself in chat channels and mailing lists of some organizations. I went through various project ideas proposed by these organizations and tried to find a project that aligned most with my interests. Being an astronomer, I wanted to work on an OpenAstronomy project and from the list of project ideas I liked the project called ‘Bexvar in Stingray’. So I decided to prepare a proposal for this project.

About the project

Let me tell you in brief about Stingray and ‘Bexvar’ first. Stingray is an open-source package for x-ray spectral timing written in python. It provides a number of tools to perform times series analysis and related tasks on astronomical light curves. In the case of faint x-ray sources, observed near the detection limits of telescopes, uncertainties in their light curves are dominated by Poissonian uncertainties. The Bayesian excess variance (Bexvar) method is useful to find variability intrinsic to sources from gappy light curves dominated by Poissonian uncertainties. It was developed by Buchner et al. (2021). The aim of the ‘Bexvar in Stingray’ project is to implement this method in Stingray, create test cases for the method based on real observational data and write appropriate documentation. I will write about the project in more detail in my next blog.

How did I make the proposal?

When I read about the project, my first instinct was to read the article by Buchner et al. (2021) to know more about the method. After reading it I was convinced that I do want to work on implementing this method in Stingray. I started by introducing myself to the Stingray community through their slack channel. As per the guideline by OpenAstronmy, one of the first things to do then was to make a PR in Stingray for the contribution period. For this, I went to the GitHub repository of the core Stingray package. I went through the list of open issues and found issues labeled ‘good first issue’ and ‘GSoC’. I selected an issue that I thought was closely related to my project. The issue was about a bug in the CrossCorrelation class in stingray. The CrossCorrelation class of stingray has an internal method called time_shift. This provided the timeshift required between two lightcurves to get maximum cross-correlation between them. It was found that if two identical lightcurves are used then, the time_shift method should give zero as the answer irrespective of the length of the lightcurve. As the light curve will have maximum crosscorrelation with itself. However, the method did not give zero as an answer in the case of the light curve having an even number of time bins. I tried to solve this issue by changing how time_shift was calculated in the code. During this time I interacted with Prof. Matteo Bachetti, who is one of the mentors for the project. Before applying for GSoC, I had negligible experience in contributing to open-source. Matteo guided me a lot during this phase and finally, my PR was merged. To be honest this made me very happy! It was the first time when I actually made some contributions to open-source software. The next task was to prepare a proposal for the project. This was a long and tough process. I spent most of my time reading about the Bexvar method, trying to understand it, and figuring out how to write a proposal for its implementation. During this time I sent my draft proposals to Matteo, he guided me to make them better, I worked on his suggestion. This interaction also gave me a lot of insight into what is expected from a contributor. This entire experience of preparing a proposal for the project and taking suggestions from mentors was quite new to me, and I am really grateful that I had a chance to go through it.

Community bonding period

After a month of submitting a proposal, the selected proposals were announced. To my surprise, my proposal was selected. I was over the moon, I was happy, I was excited and also a little bit worried. With the selection, the three-week-long community bonding period started. This period is dedicated for selected contributors to bond with community members, and mentors, interact with them and get themselves familiar with the codebase. This acts as a warm-up period before the actual coding period starts. The first important thing that happened during this period was the project kickoff meeting with my mentors Matteo and Daniela. This was the first time when I virtually met both of them. We discussed a bit about the project, our background, and current work, our expectations from each other, etc. We decided to meet every week virtually and stay in contact during the week via slack. This was a truly nice experience for me, both of them are quite supportive, they explained things to me nicely and most importantly made me feel welcome in the community and made sure that I was comfortable. In the following weeks, I spent my time studying the implementation of Bexvar by Buchner et al. (2021), learning about Bayesian statistics, and also understanding Stingray’s code base. I also learned more about testing in python and by the end of the community bonding period, I was ready to start coding. I planned to get a basic model of the method ready in the first few weeks after the community bonding period. Overall the community bonding period was great, It really helped me get into the right mindset for the coding period and be prepared for it. I learned a lot about Stingray, Bayesian statistics, and my project during this time.

A lot more is yet to be covered. Right now I am on the 3 rd week of the coding period. I will soon write about my project and my work in the coding period in detail in my next blog. It is time to wrap this one up for now. See you soon!