Blog 2: September 7th

• After hearing from Dr. Brad Miller, what are your first impressions about Runestone as an open-source project? Please explain.

n/a 

• What excites you about contributing to Runestone (if anything)? Explain.

What excites me the most about contributing to Runestone is that I will have the opportunity to add value to a project that I have personally used. The first Computer Science course I took was CSC 226, Software Design and Implementation, and one of the core assignments/tasks that we had to do throughout the semester was to read the textbook on Runestone Academy. As someone that was new to the tech field with no prior experience with coding whatsoever the experience of using Runestone was eye-opening. It was beginner-friendly, and I had the chance to practice writing Python codes directly in the textbook. I had never used an interactive textbook like this one in the past. All I had used for my courses were either a physical textbook or a pdf version of it, and often times I would have a hard time keeping up with the complex reading because it seemed very long so getting to do actual practice problems and exercises on the textbook directly removed the extra steps of me setting up or opening up another application to practice my coding and as a beginner this was a game changer. I had a very positive experience, and I remember being so confused and feeling overwhelmed because I was taking a 200-level course without any prior experience, but my experience with Runestone Academy helped relieve some of the stress and pressure because of how much easier it was to use it.  

• What worries you about contributing to Runestone (if anything)? Explain. 

n/a  

• After reading, Read Committing Code: General Rules and Git, GitHub, & Workflow Fundamentals, discuss commit messages and Git workflow and their primary purposes in the context of the open-source movement. Which guidelines make the most sense to you? Which makes the least sense?

Read Committing Code: General Rules:  
Working with the Student Software Developers Team and my experience with CSC 226, and CSC 236 I have written a lot of commit messages, I did know that the commit message has to be short, concise, and less than 50 characters, however, there was more in this reading that I was unaware of. I did not know that the commit message had to present tense and use an imperative present tense. This makes me realize that I have been cluelessly writing my messages. Reading the guidelines I understand why it has to be that way, it allows the other developer working on the same project to understand the process and progress of your work without having to communicate directly back and forth. A good commit message allows another developer to have a better understanding of the progress of work, and using imperative present tense gives commonality throughout the different commits. I have never put the issue number when writing a commit message. I didn't know it had to be written in brackets like [Closes #124]. This guideline makes the least sense to me just because I am unfamiliar with it, however, I understand that following this practice would create a structure. These guidelines help create a commonality across the project which is crucial for open open-source movement where all kinds of developers with diverse backgrounds may want to use their style. The rules of git commit messages reduce clashes that different developers may bring to the project.

Git, GitHub, & Workflow Fundamentals: 

Throughout this semester we will be adding changes to Runestone Academy which is an open source. Personally, I am pretty familiar with workflow fundamentals from my experience as a student programmer. I use these commands regularly and try to avoid merge conflicts as much as I can by following many of the practices suggested by the author of the article, Molly. The guideline that makes the most and least sense for me is git pull origin master. I do pull from origin as much as I can, but back when I was still fairly new to web development I would often forget to pull and it would cause some merge conflicts which is why I am saying it makes the least sense to me. It makes the most sense to me now, but back when I was still getting used to the workflow I made that error. 

• After reading FOSS Definitions, discuss how these definitions relate to Runestone.

"Most FOSS developers start as users of the application." This is relatable because I was also at first a user of Runestone Academy, I got the chance to utilize a couple of the products of the application such as the textbook for CSC 226 and CSC 236. I just learned about "Benevelong Dictator" a.k.a. BD I did not know that it was an actual term. From my personal experience, the BD at the Student Software Developer Team is Brian, but like it was stated in the Google doc he doesn't dictate all the decisions on his own he usually communicates with his junior developer Andersson before he states the final say. BD is relevant to Runestone because we have Dr.Pearce who will be the BD for our project and I believe we are working on csc426 textbook for Runestone Academy throughout the semester. In terms of forking, I am familiar with the term but did not know the more defined term until I read the definition. Like it was stated in the document, "forking is not an ideal situation as it may result from dispute with in the development team that cannot be resolved.", so I don't think it will be that relevant to us because we as the students of csc423 will be all collaborating and need to be able to pull new changes, and stay updated with the rest of the class. In terms of communication, I believe we will be using Git, and we are utilizing GitHub for repos. Through GitHub we will be able to track the issues, and create PRs. I am unsure if we will have a roadmap of the issues/enhancements that are needed to be added for a specific release. I have worked in a big company where we have monthly releases, and major releases where it happens once every quarter, but I am unsure if Runestone Academy does a release regularly or how often they do it.