Service: Learning Journal Reflections
Wow it's already the end of the semester as we wrap it up with CST462s. This class was quite interesting with the research project done in a group, the many ethical discussions in regards to Race, Gender, and Class in technology, and the service learning with a community driven organization. Overall I have learned a lot this semester and something that I wanted to note was that the discussions were very helpful in guiding the class materials, and it made the class feel engaging each week.
In regards to the service learning, I had to serve The Document Foundation as a Quality Assurance contributor. In my case I served around 37 hours working on bug testing via an approach called Bug Triaging within a forum based bug report system called BugZilla. Bug Triaging was described by my service organizer as a process that helps analyze, evaluate, prioritize and assign software bugs to ensure the essential and important issues are dealt with first by developers. The service was actually quite fun as I began progressing through the essential steps to completing a successful triage throughout the 6 weeks of contributions. I thought the overall experience went well, the orientation/on-boarding was straightforward, and my service organizer/mentor Ilmari was very patient and understanding especially in regards to the time constraints I had during the semester. We organized meetings once a week on Thursdays through IRC chat via Libera Chat and had some pretty thoughtful discussions in regards to software development and the positive notions of open source projects.
The main thing that went well with the service was when I was correctly going through all the steps of a successful bug triage and efficiently finding reports that needed to undergo what is called Bibisecting. By doing bibisecting we are able to find certain commits using the git procedure bisecting on binary repositories that contain a range of commits of previous software versions. It was essentially a binary search on many git commits. I actually found many bugs that required fixing and made relays to the developers to get them fixed throughout my service. My task was to find commits that may have caused a regression, or in this case where the developer may have made a change to the version and inadvertently caused another issue in the process. In many instances, I was tasked to find the fix where maybe the latest version had the issue fixed and I had to find the commit so that it could be relayed to the developer in order to backport it to older versions. Overall I thought the whole process of bibisecting and navigating bug reports went well. Something I could improve on was writing scripts to automate the bibisecting, but Ilmari did mention that usually I would have to manually test the reports. Another improvement I would make is better time management due to the time conflict with meeting with the service organizer during the timezone difference. I may have missed one meeting due to this reason.
The most impactful part about this experience was learning how quality assurance is processed in an open-source software organization. It was interesting finding that many of the people reporting were also volunteers and users from different countries so it really opened my eyes about the diverse nature of an organization like this. The challenges I faced were dealing with bug reports that were very hard to distinguish due to the language barriers of many users. There were plenty of times where I had to ask other contributors if they understood what the person was posting, and frequently I had to confront the user without being too rude. It definitely enhanced my experience of being a professional in a work environment and improved my communication skills. There were also moments where I needed to thoroughly construct a good report to relay to the user and developer, so I had to pick my words carefully in order to clearly pass on my descriptions and findings.
I want to end this by giving some advice to the future SL students that may be involved in The Document Foundation. When you first start the service and get the email from Brianna or whoever is assigning you the service learning organization project, immediately email the service to start the on-boarding. Starting as early as possible will give you some leeway in the later weeks to focus more on your research project assignment and it will help set up the meeting hours for the future. Additionally, I want to mention the proper scheduling one should take. In many cases it felt pretty easy to fall behind if you missed some hours. Something that worked for me this semester was committing to around 2-3 hours every 2-3 days, or essentially just doing around 6-7 hours a week. By doing this I had already finished my hours by around week 6. I also completed a few extra hours just to be a bit safe. To go along with the scheduling, I suggest requesting the approval of hours each week instead of waiting for the last minute/week of the semester. Lastly, I want to mention that you should not be afraid to ask questions if something is confusing. Ilmari is quite patient and is willing to help guide individuals at any pace necessary. Also if you can do bug testing on MacOS then you would have a pretty easy time since there are so many that haven't been touched. Most reports involved are with Linux and Microsoft.
In regards to the service learning, I had to serve The Document Foundation as a Quality Assurance contributor. In my case I served around 37 hours working on bug testing via an approach called Bug Triaging within a forum based bug report system called BugZilla. Bug Triaging was described by my service organizer as a process that helps analyze, evaluate, prioritize and assign software bugs to ensure the essential and important issues are dealt with first by developers. The service was actually quite fun as I began progressing through the essential steps to completing a successful triage throughout the 6 weeks of contributions. I thought the overall experience went well, the orientation/on-boarding was straightforward, and my service organizer/mentor Ilmari was very patient and understanding especially in regards to the time constraints I had during the semester. We organized meetings once a week on Thursdays through IRC chat via Libera Chat and had some pretty thoughtful discussions in regards to software development and the positive notions of open source projects.
The main thing that went well with the service was when I was correctly going through all the steps of a successful bug triage and efficiently finding reports that needed to undergo what is called Bibisecting. By doing bibisecting we are able to find certain commits using the git procedure bisecting on binary repositories that contain a range of commits of previous software versions. It was essentially a binary search on many git commits. I actually found many bugs that required fixing and made relays to the developers to get them fixed throughout my service. My task was to find commits that may have caused a regression, or in this case where the developer may have made a change to the version and inadvertently caused another issue in the process. In many instances, I was tasked to find the fix where maybe the latest version had the issue fixed and I had to find the commit so that it could be relayed to the developer in order to backport it to older versions. Overall I thought the whole process of bibisecting and navigating bug reports went well. Something I could improve on was writing scripts to automate the bibisecting, but Ilmari did mention that usually I would have to manually test the reports. Another improvement I would make is better time management due to the time conflict with meeting with the service organizer during the timezone difference. I may have missed one meeting due to this reason.
The most impactful part about this experience was learning how quality assurance is processed in an open-source software organization. It was interesting finding that many of the people reporting were also volunteers and users from different countries so it really opened my eyes about the diverse nature of an organization like this. The challenges I faced were dealing with bug reports that were very hard to distinguish due to the language barriers of many users. There were plenty of times where I had to ask other contributors if they understood what the person was posting, and frequently I had to confront the user without being too rude. It definitely enhanced my experience of being a professional in a work environment and improved my communication skills. There were also moments where I needed to thoroughly construct a good report to relay to the user and developer, so I had to pick my words carefully in order to clearly pass on my descriptions and findings.
I want to end this by giving some advice to the future SL students that may be involved in The Document Foundation. When you first start the service and get the email from Brianna or whoever is assigning you the service learning organization project, immediately email the service to start the on-boarding. Starting as early as possible will give you some leeway in the later weeks to focus more on your research project assignment and it will help set up the meeting hours for the future. Additionally, I want to mention the proper scheduling one should take. In many cases it felt pretty easy to fall behind if you missed some hours. Something that worked for me this semester was committing to around 2-3 hours every 2-3 days, or essentially just doing around 6-7 hours a week. By doing this I had already finished my hours by around week 6. I also completed a few extra hours just to be a bit safe. To go along with the scheduling, I suggest requesting the approval of hours each week instead of waiting for the last minute/week of the semester. Lastly, I want to mention that you should not be afraid to ask questions if something is confusing. Ilmari is quite patient and is willing to help guide individuals at any pace necessary. Also if you can do bug testing on MacOS then you would have a pretty easy time since there are so many that haven't been touched. Most reports involved are with Linux and Microsoft.
Comments
Post a Comment